（计算机应用技术专业论文）基于web的研究生毕业信息系统开发.pdf

摘 要 i 基于 web 的研究生毕业信息系统开发 学 科： 计算机应用技术 研 究 生： 徐 蓓 (签名： ) 导 师： 张 璟 教授 (签名： ) 答辩时间： 2005 年 3 月 摘 要摘 要 研究生毕业信息系统是一个典型的分布式现代信息管理应用系统， 系统依托校 园网和因特网实现研究生培养、 毕业生信息管理， 提高了研究生管理工作的开放性， 减轻教务管理工作的压力，为教师和学生提供快速、便捷、开放的服务，为学校的 研究生工作提供有效的决策支持。 在系统的开发过程中，本文在深入研究了现有的 uml 建模方法，提出了基 于角色的业务流程分析方法和业务角色流程驱动的用例分析方法， 定义了一个简洁 的基于 uml 的软件建模过程。 在此基础上给出了研究生毕业信息系统的业务模型。 针对该模型展开了具体分析，抽象出了系统分析阶段的静态模型及动态模型，然后 把系统静态模型中的持久对象映射到数据库和分布式对象上， 继续细化分析阶段的 动态模型，得到设计阶段的动态模型，最后利用.net 框架以及 web service 技术实 现了动态模型中的具体业务。 关键字：关键字：研究生毕业信息系统、uml、面向对象 abstract ii research & develop gradutae students graduation information system based on web speciality: computer application technology author: xu bei (signature: ) supervisor: prof. zhang jing (signature: ) abstract the graduate students graduation information system is a typical distributed modern information management application system, the system relies on campus network and internet and realizes the information management of graduate students training and graduating, improve the opening of graduate students management, lighten the pressure of the educational administration management, offer effective decision support for graduate student of the school work. in the course of systematic development, this text is further investigating existing uml modeling method , the ones that have put forward the business procedure analytical method based on role and business roles procedure and driven have used the analytical method of the example, have defined a succinct software modeling course based on uml. provide graduate student graduate business model of information system on this basis. having launched making a concrete analysis of to this model, static models and dynamic models at stage of system analysis have happened abstractly, is it get system lasting target of static model database and at the distributed target to shine upon, continue to analyze the dynamic model at stage, get the dynamic model on design phase, make use of .net frame and web service technology to realize the concrete business in the dynamic model finally. keywords: graduate students information system, uml, object-oriented 绪论 1 1 绪论绪论 1.1 课题来源和研究目标 本课题来源于我校研究生部，是整个研究生部综合管理系统的一部 分。系统目标是建立一个研究生教务管理工作信息化平台，依托校园网 和因特网实现研究生培养、毕业生信息管理等功能。 系统的实现提高了研究生管理工作的开放性，减轻教务管理工作的 压力，为教师和学生提供快速、便捷、开放的服务，为学校的研究生工 作提供有效的决策支持。 1.2 研究背景及意义 开展本课题研究之前，我校研究生部已有部分研究生教务管理系统， 但实现的管理业务有限，大部分教务管理工作还没有实现信息化；已有 的信息系统分散，数据无法共享；目前的管理系统仅限于教务人员使用， 研究生和教师与研究生部信息交互功能还使用传统手工方式；研究生部 还没有对外发布信息的 web 站点，不便对外宣传、交流和招生工作。 经过调研发现，在国内其他院校，研究生管理信息化也是刚刚兴起。 不少系统都存在着系统孤立，业务不完整的情况。整个系统平台能在校 园网和 internet 环境下使用，实现动态管理的还不多。在这种情况下，进 行研究生电子教务系统研究开发，对于实现研究生毕业管理信息化、网 络化，提高研究生教育质量与管理水平，具有重要的现实意义。 1.3 课题建模技术 面向对象技术，目前已经成为一般应用系统开发的主流技术，得到 了众多的应用软件开发平台和开发语言的支持。但是，要充分发挥面向 西安理工大学硕士学位论文 2 对象语言和平台的优势，利用对象技术开发出结构清晰、可重用强的软 件系统，就应该进行正确的面向对象的系统分析设计。 传统的结构化方法分析、设计的成果不能直接映射到客观世界的实 体上，也就是说，解空间结构与问题空间的结构不一致。同样，利用结 构化分析方法，也无法得出一个面向对象的软件系统模型。没有面向对 象的软件模型，也就无法发挥出面向对象开发工具的特长，无法构建一 个真正意义上面向对象的软件系统。 因此，应该采用面向对象的分析、设计方法设计出完整的系统对象 模型。这样才能利用现有的面向对象软件开发工具，进行面向对象的软 件系统开发。 在研究生毕业信息管理系统的开发过程中，我们研究并提出了一个 基于 uml 的建模过程方法，这一方法可以适应使用 uml 进行面向对象 系统分析及设计各阶段的工作。 由于 uml 图形众多、表示方法丰富，使得在具体使用时不容易确定 具体图形的用法。本文结合我们的实际开发经验，给出了工作流程和图 形的对应关系。具体工作流程如下： (1) 业务建模 业务建模是对问题领域中组织机构的抽象。主要完成业务领域过程 和业务对象的定义。采用方法：基于角色的业务流程分析、业务角色流 程驱动的业务主角流程分析。 主要成果为业务角色、业务对象、业务用例图、活动图。 (2) 需求分析 针对领域业务对象模型，建立系统的静态对象模型，寻找系统用例， 建立系统的用例模型。 主要成果为活动者、用例图，也可以使用活动图表示动态业务系统 需求。 (3) 设计系统体系结构模型 绪论 3 选择并设计软件体系结构模型，为系统设计提供软件开发模式。主 要成果为应用系统的软件设计模式。体现了以体系结构为中心的设计方 法。 (4) 面向设计模式的用例事件流分析 按照设计模式，建立系统的动态对象模型。用顺序图对用例进行事 件流分析，描绘出用例涉及的对象和对象间的消息模型，得到系统的分 析模型。采用方法：用例驱动的系统分析。 主要成果为顺序图、协作图和状态图。 (5) 类设计 在得到了系统用例场景对象之后，可以将对象映射到需要实现的类。 通过详细设计对象和对象间的消息，可以得到完整的类，包括类的属性、 方法和事件。在类设计之前，可以针对对象分析模型中的对象进行泛化 和聚合。同时可以根据用例将得到的类划分到不同的包中。从而根据类 设计得到了系统的设计模型。 主要成果为包、类和包图、类框图。 (6) 组件设计 根据系统需要的粒度大小，将得到的类进一步分配到最终用来构成 系统的组件中，目的是方便软件的安装和部署。同时可以设计出组件的 接口，抽象出组件的外观。 主要成果为组件、接口、组件图。 (7) 编码实现 在完成了软件的分析设计后，就可以使用特定的开发语言实现软件 系统。如果使用 case 工具支持自动生成程序，就可以针对特定语言完 善系统的设计模型，以便使用工具提供的语言插件生成系统类库框架和 组件结构。 (8) 软件测试 根据系统需求确定测试模型，生成测试用例，验证软件功能。在测 西安理工大学硕士学位论文 4 试结果不能满足需求时，修改设计方案，进入开发循环。 (9) 部署安装 设计部署模型，确定需要的计算机等设备，以及设备间的连接关系。 并设计软件组件在设备上的部署情况，最终将得到系统的部署图。 为保证实现后的系统，能够满足需求，代码能够对应到需求，必需 建立可跟踪过程，定义出设计结果的回溯关系。本文定义的用于跟踪需 求与系统用例的过程如图 1-1 所示。 业务 用例 业务 用例 系统 用例 系统 用例 组件 图 组件 图 类图类图 顺序图 协作图 顺序图 协作图 事件 流 事件 流 代码代码 图 1-1 需求的可跟踪性图 以上提到的设计过程，是为了加快 uml 设计速度提出的一个清晰、 简洁的设计过程，根据实际系统的开发需要，采用合适的 uml 图形进行 表示。在实际设计的过程中，还必须注意工作流程的迭代，这样才能逐 步完善系统模型。 业务模型与流程描述 5 2 业务模型与流程描述业务模型与流程描述 本文采用基于 uml 技术的用例驱动型可视化对象建模方法。 2.1 建立业务模型 系统建立业务模型是采用基于角色的流程分析方法，以业务领域中 的人为主线，将不同的人进行分类定义不同的角色，然后通过分析不同 业务角色涉及的业务流程，得到了比较完整的领域业务模型。 2.1.1 确立业务角色 2.1.1 确立业务角色 角色是与所建系统交互的人、物或系统等。用例描述系统内的一切， 而角色描述系统外的一切。角色可以分为实例角色和抽象角色。通过研 究生教务业务的分析，得出了一个抽象角色：教务管理人员，它包含三 个实例角色：招生办教务人员、培养科教务人员、学位办教务人员。还 有实例角色三个：在校研究生、导师、任课教师等。角色的关系如图 2-1 所示： 任课教师 导师在校研究生 抽象角色 招生办教务人员 培养科教务人员学位办教务人员 教务管理人员 学院研究生秘书 图 2-1 研究生毕业信息系统角色 西安理工大学硕士学位论文 6 2.1.2 建立业务流程建立业务流程 针对上节定义出的每个角色，分析业务角色的日常工作涉及的一系 列的业务流程，可以分析出大部分的业务用例，建立业务模型。其中研 究生从入学、培养到毕业的整个流程，是系统业务领域中最重要的一个 业务流程，研究生的培养、毕业管理工作都是围绕着这一流程进行的。 所以我们以这个流程为主线，详细列出了培养、毕业流程中的所有环节， 同时对其他角色的业务流程也进行了详细分析得到了系统业务模型的外 观。具体过程如下： 1.研究生毕业信息系统业务流程分析1.研究生毕业信息系统业务流程分析 研究生毕业信息系统业务流程如图 2-2 所示。 在研究生毕业信息系统业务流程中我们定义了一些关键事务，其中 包括： (1)研究生填写学籍信息事务：包括了研究生填写完学籍表后，将学 籍表交回研究生部，研究生部确认接收保管的整个业务过程。制定个人 培养计划事务：包括了研究生选择课程完整填写个人培养计划后，将制 定个人培养计划交回研究生部，研究生部确认接收保管的整个业务过程。 (2)导师制定个人培养计划事务：包括了研究生导师选择培养课程， 完整填写研究生个人培养计划后，将个人培养计划交回研究生部，研究 生部确认接收保管的整个业务过程。 (3)任课教师提交成绩事务：包括了任课教师填写完所代课程成绩， 将成绩单交回研究生部，研究生部确认接收保管的整个业务过程。 (4)研究生提交开题、 答辩、 论文资料事务：包括了研究生填写开题、 答辩、论文信息表后，将这些信息交到研究生部，研究生部确认接收保 管的整个业务过程。 (5)学院办秘书资格审查事务：包括了研究生秘书填写完毕业资格审 查学生表后，将毕业生名单一起交到研究生部，研究生部确认接收保管， 业务模型与流程描述 7 并且最后生成上报数据的整个业务过程。 图 2-2 研究生毕业信息系统业务流程图 这里定义的事务，将对后期的软件系统设计提供参考。 2.研究生毕业信息系统业务流程状态分析 2.研究生毕业信息系统业务流程状态分析 在分析了研究生毕业信息系统的业务流程后，我们可以以时间流程 为顺序定义出研究生在培养毕业过程的一些关键状态， 状态集 c=拥有学 籍、制定个人培养计划期、课程学习期、开题准备期、课题研究期、论 文答辩期、毕业准备期、学位申请期、办理离校手续期，状态转换图如 西安理工大学硕士学位论文 8 图 2-3 所示，其中定义了状态转换的条件。 图 2-3 研究生毕业信息系统业务流程状态图 2.1.3 建立业务用例 2.1.3 建立业务用例 通过对业务流程的分析，可以得到研究生毕业信息系统业务流程涉 及的用例。通过对在校研究生的业务分析，得出在校研究生业务用例， 即：提交学籍信息、提交开题信息、提交答辩论文信息、提交毕业信息、 查询个人考试成绩、查询个人培养计划，用例图如 2-4 所示。 图 2-4 在校研究生业务用例图 业务模型与流程描述 9 对研究生培养科教务管理人员的业务分析，得出了研究生培养科教 务管理人员业务用例，即管理学籍信息、管理个人培养计划、管理研究 生成绩、管理开题信息、管理答辩信息、管理论文信息、管理毕业生信 息。研究生教务管理业务用例图如图 2-5 所示。 图 2-5 研究生培养科教务人员业务用例图 2.2 系统用例抽取系统用例抽取 抽取用例主要是分析提取用例，去除用例之间的覆盖，并从计算机实 现的角度对相关用例做进一步的抽象。抽取用例的过程也称为用例的结 构化，它的结果将对分析阶段的划分分析包和从用例中分析类产生直接 影响。 通过对业务用例的分析，可以得到整个系统的用例图。研究生毕业 管理信息系统用例包含两个顶层用例：培养管理用例和毕业管理用例。 而它们又可以继续化分为子用例，培养管理用例包含：管理学籍信息、 管理培养计划、管理成绩、管理开题答辩这四个子用例；毕业管理用例 包含：审查毕业资格和管理毕业生信息这两个子用例。研究生毕业管理 信息系统顶层用例图如 2-6 所示： 西安理工大学硕士学位论文 10 管理学籍信息 管理培养计划 管理开题答辩 审查毕业资格 毕业管理 在校研究生 管理毕业生信息 培养管理权限验证 培养管理 在校研究生 毕业管理权限验证 管理成绩 任课教师 导师 培养科教务人员 培养管理 培养科教务人员 毕业管理 图 2-6 系统用例图 继续按业务流程，对每个此层用例进行业务分析，得到系统的第二 层用例图，如图 2-7 所示： 业务模型与流程描述 11 图 2-7 系统第二层用例图 西安理工大学硕士学位论文 12 2.3 细化用例细化用例 根据上一节中用例的描述方法，可以对系统的用例进行分析，详细 描述每个用例的处理。前面已提到，用例是从用户角度出发描述外界与 系统的交互，所以这个过程应该是与用户不断交流的过程，直到用户对 得出的用例满意为止。然后，这些用例将在以下各步骤中起到推动整个 开发过程的作用。细化一个用例的主要任务是从细节上描述它的事件流， 包括它是如何启动和结束的，是如何与角色进行交互等。 研究生毕业信息系统的业务用例数量较多，仅对毕业管理用例中的 部分用例进行说明。在此以毕业资格审查这个子用例为例，对毕业资格 审查用例进行详细分析与说明，其他所有子用例的设计过程与结果与此 类似。 1用例名称：毕业资格审查 2概述：学院研究生秘书对将毕业的研究生进行资格审查，向研究 生部毕业生名单； 3上下文图： 学院研究生秘 书 毕业生表 审查毕业资格 学位信息表 4前置条件：在学生修满课程，提交答辩、论文信息后； 5事件流： (1)基本事件流： 1) 学院办秘书向系统发出“审查毕业资格”请求； 2) 系统要求学院办秘书选择将毕业研究生所在年级； 3) 学院办秘书做出选择后， 显示该院所在级的所有研究生列 业务模型与流程描述 13 表， 可让学院办秘书对中间的每个研究生查询他们的成绩 单和论文答辩信息； 4) 学院办秘书在查询完他们的相关信息后； 5) 选择、提交满足毕业条件的研究生； 6) 系统将确认录入名单和数据库表中的研究生是否有重复； 7) 系统将录入名单存储进库； 8) 用例结束； (2)扩展事件流： 6a) 如果录入名单有重复，则显示当前重复的研究生学号并 要求学院办秘书筛出该生，转到 5） ； 6子用例图： 查询成绩 更新毕业生表 查询答辩论文信息 更新学位信息表 西安理工大学硕士学位论文 14 3 系统分析 3 系统分析 面向对象系统分析的基本任务是：运用面向对象方法，对问题域和 系统责任进行分析和理解，对其中的事物和它们之间的关系产生正确的 认识，找出描述问题域以及系统责任所需的类及对象，定义这些对象的 属性和操作，以及它们之间的静态和动态关系。最终产生一个符合用户 需求，并能够直接反应问题域和系统责任的问题域模型及其详细说明。 具体来说，分析模型和用例模型最大的不同就是分析模型使用开发 人员的语言进行描述，并且反映系统的内部视图。分析阶段的活动主要 是：发现对象；为对象分类；确定类的属性和操作；确定类之间的关系； 确定对象之间的交互；确定对象的状态变化等。 3.1 分析类确定 本节以研究生毕业管理子系统为例，给出了系统的用例分析方法和 过程。设计出子系统中更为细致的静态对象模型。 3.1.1 寻找对象 3.1.1 寻找对象 通过对用例事件流的分析，从与其有关的用例中抽取出与该对象有 关的消息，形成该对象完整的对外界面，并根据需求描述及分析模型， 对该对象的需求加以完善，然后根据对象所承担的任务和角色，确定对 象的内部结构，定义构成该对象的类结构，作为对象实现的主要依据。 研究事件流中的名词是寻找对象的好办法，另一个办法是查阅情境 文档。情境是事件流的特定实例。以顶层用例“毕业管理”为例，寻找 到如图3-1所示的对象图： 系统分析 15 图 3-1 毕业管理子系统对象图 3.1.2 确定分析类 3.1.2 确定分析类 可以检查时序图和协作图中的对象。通过对象的共性即可寻找类。 时序图和协作图中的每个对象都要映射相应的类。从用例的事件流中， 研究一些名词也可以知道某些类。在面向对象软件工程方法中，将类分 为三种：实体类、界面类和控制类。 (l)实体类 实体类用于为系统中长期存在的信息建模。在通常情况下，实体类 西安理工大学硕士学位论文 16 直接来自业务模型中的相应业务对象。实体类可以从各个用例的交互图 中抽取与计算机处理相关的对象转化而来。通过对毕业管理子系统的所 有用例分析后，可以得到以下的实体类： 表 3-1 毕业管理子系统的实体类 实体类名称 实体类属性 研究生信息 学号，姓名，专业，学院，年级 等 论文信息 学号，论文题目，摘要，关键字，著作年 等 答辩信息 学号，课题名称，答辩日期，评审表 等 成绩单 学号，课程名称，成绩 等 毕业生 学号 毕业生信息 学号，姓名，专业，学院，培养方向 等 学位信息 学号，姓名，专业，授予学位学科名称 等 上报毕业生信息 学号，姓名，专业，培养单位，考生号，身份证号 等 (2)界面类 界面类用于系统与角色之间的交互，包括从用户和外部系统接收信 息和请求，这个分类还被称为“接口类” 。界面类为依赖于角色的系统部 分建模，它们解释和汇集系统边界需求。界面类经常代表窗口、表单、 交互界面等，它描述交互所能得到的结果而不是交互的物理实现。可以 通过检查用例图和交互图来寻找界面类。 对界面类，分析阶段不必指出用户的每个窗口的构件，只要说明通 过交互所实现的目标就可以了。表 3-2 中列出了毕业管理子系统的界面 类。 表 3-2 毕业管理子系统的界面类 界面类名称 界面类职责 提交毕业信息界面 研究生录入学生毕业基本信息 毕业资格审查界面 学院办秘书对毕业生名单审查、提交 生成毕业上报数据界面 培养科教务人员对当年毕业数据生成.dbf 文件 系统分析 17 (3)控制类 控制类用于系统内的模型行为，用于对一个具体用例的控制或其他 业务逻辑建模。系统的动态机制由控制类来建模，因为他们处理与协调 主要活动和控制流，将工作分派给其他对象。控制类封装了对某些对象 的控制、协调和事务处理，这样就可以将控制的变化孤立在某个类中了。 我们将毕业管理子系统中的业务逻辑抽象为以下的控制类： 表 3-3 毕业管理子系统的控制类 控制类名称 控制类职责 查询研究生 根据查询要求列出在校研究生列表 查询成绩 根据学号查询列出某学生全部课程成绩 查询答辩、论文信息 根据学号查询列出某学生答辩、论文信息 写入.dbf 毕业上报库 对毕业符合要求的毕业生写入上报文件中 创建新的毕业生 将符合毕业要求的研究生加入毕业生和学位信息表 3.1.3 类属性和类操作 3.1.3 类属性和类操作 类的属性是类的信息包含。一个属性一般都描述类的某个特征，因 此可以用来识别某个对象。从一般意义上来说，一个类所对应的实体(或 一个概念)具有很多不同的特征，但在某个特定系统的问题域中，我们只 对其中的某些特征感兴趣，这些特征将成为该类的候选属性。 为了有效地识别属性，我们运用 rumbaugh 提出的 7 条原则来检查 每个候选属性，从而确定属性；运用 shlaer 和 mellor 推荐的六个原则来 复查属性，并进行必要的调整。经过问题域分析后剩下的候选属性通常 都极有可能成为正式的属性，但如果对于问题域分析得不透彻，则往往 还要针对每一个候选属性进一步检查。 类属性的识别不是一件轻松的事情，它需要反复多次才能完成。类 属性的修改通常并不影响系统结构，可以采用增量式或者迭代的过程来 识别类的属性。 西安理工大学硕士学位论文 18 类操作的识别的方法很多。本论文中采用的是从协作图中识别类的 操作的方法。面向对象系统是通过对象之间的相互发送消息来完成系统 功能的。对象之间的交互或合作可以实现用例中的功能。协作图中，对 象传递的消息就可以映射为对象的操作。因此，可以通过协作图来识别 类的操作。这种方法充分体现了“用例驱动”的思想。 在分析阶段，可以不识别某些控制类的属性和操作，因为在设计阶 段需要结合相应的实现技术，它的一些属性和操作就有可能改变。 3.2 分析类图 在建立系统的分析模型中，最重要的工作是确立系统的类图。类图 是用来描述系统中类的静态结构。 建立类图，需要定义类之间的关系。 类和类之间的关系主要有以下几种： 关联、依赖性、聚合、实现、一般 化。 对类之间关系进行分析后，我们得到毕业管理子系统的类图。这里 是以子系统中实体类的类图为例。如图 3-2 所示： 图 3-2 毕业管理子系统实体类图 系统分析 19 3.3 分析包 类是面向对象设计的核心，它封装了对象的属性和行为。一个系统 可能由多个类组成的，因而可以将多个功能相关的类划分到一起，形成 一个系统包。包的划分实际上是划分功能子系统的过程，包更有利于类 的组织。分析包提供了一种方法，以可管理分块的方式，对分析模型的 制品进行组织。通过识别具有很强语义联系的建模元素的分组找到分析 包。我们将分析类作为分析包的来源。 良好的包结构的关键是：包内高内聚、包间低耦合。当创建分析包 模型时，应该保持简单以及避免嵌套包。 如果分析包的内容彼此相关联，就定义分析包之间的依赖。当两个 或多个分析包需要共享一个分析类时，可将其取出来做为一个共享类， 将它放在一个独立的分析包中，其它的包依赖于这个通用的包或者类。 在创建包依赖关系时，要尽量避免循环依赖性。处理循环依赖性， 可以将一个包一分为二。例如：a、b 两个包，a 中的某些类要知道 b 中 的某些类，b 中的某些类要知道 a 中的某些类。可以将 b 包中 a 包所依 赖的类移到 c 包中。 在分析中，可以将分析类划分为以下几个包：用户边界包、边界接 口包、数据处理包、数据包等。如图3-3所示： 用户界面包 数据处理包 数据包 持久对象包 业务实体包 边界接口包 图 3-3 系统包图 西安理工大学硕士学位论文 20 用户边界包中主要是包括所有的用户界面类。边界接口包是用户和系 统的接口。所有的控制类分为请求处理包和数据处理包。业务实体包和持 久数据包中都是实体类。它们之间的区别在于业务实体包中的实体将会在 应用程序中出现，持久数据包中的实体存放在数据库中。数据处理包和数 据包之间存在的使用关系，表示数据处理包可以使用数据包中公用的元素。 3.4 用例实现分析 类图只是从静态角度来描述系统，系统的动态特征和行为可以通过 用例实现来描述。用例实现由一组类所组成，这些类实现了用例中所说 明的行为。用例实现是在用例的系统行为中捕获的某个方面的规格说明 和相关的补充需求，通过已经识别的分析类实例间的合作和交互建模如 何实现这种需求。 用例实现可以通过协作图、活动图、顺序图和状态图来完成。顺序 图是最常用的动态模型。应用程序总是需要产生顺序图。顺序图以时间 为中心，其重点是对象之间消息的线性流动。协作图以对象实例为中心。 如果应用程序的某个特定方面是多线程的，那么协作图要优于顺序图。 从分析中所得到的用例的路径都不复杂，所以在用例实现中，主要是以 顺序图和协作图为主。 在毕业管理子系统中，有一个毕业资格审查的用例。这个用例是通 过学院秘书、毕业资格审查界面、查询研究生、查询成绩单、查询答辩 论信息、重复学生检查、研究生信息、成绩单、答辩论文信息、毕业生、 毕业生信息、学位信息类之间的交互来完成的。如图 3-4 所示的顺序图 就反映了这个用例的实现。 系统分析 21 图 3-4 毕业资格审查用例实现时序图 3.5 分析模型 对研究生毕业信息系统进行需求分析和系统分析后，可以得到系统的 分析模型。分析模型是全面地展示了将分析阶段所得到的分析类和它们之 间的关系。它体现了系统的静态结构。 西安理工大学硕士学位论文 22 图3-5 系统的分析模型 系统设计 23 4 系统设计与实现系统设计与实现 面向对象的设计阶段是对分析结构的进一步精化。分析侧重于理解问 题域，设计则侧重于解决方案。分析模型是设计模型的基础。设计的成果 可以作为程序员编码的依据和指导。设计阶段主要完成三个工作：系统体 系结构设计，业务对象设计和持久对象设计。 4.1 系统体系结构设计 系统采用b/s模式实现系统的核心管理操作功能， 同时利用新的.net 平台下的xml web service技术，来实现公共信息收集、发布、查询功能， 研究生毕业信息系统的软件体系结构如图4-1 所示： 数据库服务 器 数据库服务 器 ie浏览器ie浏览器 .net程序集应用服务器程序集应用服务器 其他数据源 客户端 其他数据源 客户端 表示 层组 件 表示 层组 件 xml web servic e 业务层组件业务层组件 数据服务中间件数据服务中间件 系统框架层组件系统框架层组件sql server 2000 图4-1 系统软件体系结构图 总体结构中三层功能的作用分别为: (1)表示层：为客户端提供对应用程序的访问，同用户交互，调用业 务功能等。在本系统中web层由asp.net web窗体和代码隐藏文件组成。 web窗体是由html以及各种web控件来提供用户操作界面， 而代码隐藏 文件实现各种控件的事件处理。 (2)业务层：实现各种业务规则和逻辑。将已经完成的系统功能，根 西安理工大学硕士学位论文 24 据各个模块的需要，对业务规则进行高层次的封装，完成外部对业务的 调用。在本系统中采用了web service 技术对其进行了封装。 (3)数据服务层：为业务规则层提供数据库操作的服务。为了统一对 数据库的访问方式，本系统设计的框架类库中包含了数据访问服务，封 装了.net 框架上的ado.net 中的各种数据库访问和操作对象，实现了 常用的对各种数据库的操作，可以访问不同类型的数据库。这一层通常 执行的操作包括：连接数据库、执行数据库操作、数据库事务操作等。 4.2 子系统的划分 对于较大的系统的开发，还需要考虑将整个系统划分为若干子系统。 子系统指的是一组关联紧密的类。这样做可以简化复杂的设计工作，并且 可以将各子系统的设计任务分配给不同的设计者。在分布对象设计中，子 系统的划分可以决定对应单元的分布。子系统的划分需要对系统进行合理 的抽象，尽量减少子系统之间的依赖性。 在定义和设计子系统时，可以遵循以下的设计标准： (l)子系统应具有良好定义的接口，通过接口和系统的其余部分通信。 (2)除了少数接口类，子系统中的类仅与该子系统中的其他类协作。 (3)子系统的数量不应太多。 在 uml 中，用包的衍型来表示子系统。如图 4-2 所示， 研究生毕业信息系统可以划分为两个子系统。 图4-2 研究生毕业信息的系统子系统图 系统设计 25 4.3 业务对象(类)设计与实现 业务对象设计的目标是设计出系统需要实现的软件逻辑元素，通过 子系统设计可以得到整个系统的软件逻辑模型。在此本论文仅给出毕业 管理子系统的软件设计结果。 4.3.1 设计类 4.3.1 设计类 分析类侧重处理功能性需求，确定了系统中的关键类，是概念性的、 粗略的类。设计类是己经完成了规格说明并且能够达到被实现程度的类， 有详细的属性和方法，并且制定了实现类的一些细节。它是在分析类的 基础上进行深入和精化。 我们可以通过以下方法结合具体的体系结构和设计模式来完成设计 类： (1)将分析模型的类映射到应用类，把只有业务上意义的类转换成实 现上的结构，同时保持到问题域的可回溯性。 (2)对对象行为和性质细节建模，并产生精化类。 (3)设计与领域无关的用于系统功能的服务类。 4.3.2 详细设计 4.3.2 详细设计 分析模型中分析类具体分为三种构造型：边界类、实体类、控制类。 在从分析类向设计类映射过程中，三种分析类有所区别，具体如下： 1.边界类到设计类 边界类最终是用来构造系统用户界面和系统接口的。边界类的设计 常常依赖具体的 gui 实现工具环境。 2.实体类到设计类 在分析模型中，实体类是用于表示长效、持久的信息。实体类的设 西安理工大学硕士学位论文 26 计常常和特定的数据库技术密切相关。在具体设计时，实体类被映射为 持久性的设计类，并且这类设计类会被用来映射为关系数据模型中的数 据表。 3.控制类到设计类 控制类代表对其他分析类的控制和协调，他们被映射为相应的具有 事务性质或控制协调性质的设计类。这些设计类可能用来封装时序、协 调其他对象或者实现纯粹的业务逻辑。 本系统采用了基于.net 的体系结构来创建整个系统。在分析阶段建 立系统的分析类时，确定了系统的边界类、控制类和实体类，这是对系 统功能的概念性抽象。在设计阶段，要根据实现所采用的技术规范和设 计模式对系统分析类进行重新识别。具体到.net 规范，控制类映射为业 务逻辑类（对于前台信息服务系统，还要多映射出一个 webfuwu 类， 它是对后台业务逻辑组件的封装，使得前台信息表示层类可以与后台管 理表示层类共享重复的业务逻辑，在下一节组件技术设计中介绍），边 界类映射为 web 页面，实体类映射为数据持久对象或者业务实体类。如 图 4-3 所示的是用例毕业资格审查分析类映射到设计类。确定了类的属 性和操作后，接下来就是添加具体代码的工作。 系统设计 27 图 4-3 毕业资格审查用例的分析类映射设计类 4.3.3 用例实现设计 4.3.3 用例实现设计 分析阶段的用例实现决定并且实现了非功能性需求，其焦点是捕获 系统应该做什么。设计阶段的用例实现关心的是系统将如何去实现。它 西安理工大学硕士学位论文 28 由设计交互图和设计类的类图，这两个主要的活动组成。设计类的类图 体现了实现类之间的关系，是系统实现的基础。交互图对开发人员更加 深入地理解系统具有指导作用。 下面同样以毕业资格审查用例为例，来描述这个用例在设计阶段的 实现(类图、顺序图和协作图)。 图 4-4 毕业资格审查用例实现时序图 为了尽快使开发者理解该用例的实现情况，我们在设计文档中添加 了该图的文字说明。结合实际的开发技术和设计模式，该用例实现步骤 系统设计 29 如下: 1.学院办秘书打开毕业资格审查页面。 2.在页面上选择毕业年级（grade） 。 3. 提 交 后 ， 系 统 会 调 用 webfuwu_ 毕 业 资 格 审 查 .asmx 中 的 querystudent(grade)方法。 4. webfuwu_毕业资格审查.asmx 中的 querystudent(grade)方法调用 cls_毕业资格审查.cs 中相同名字的 querystudent(grade)方法。 5.在 cls_毕业资格审查.cs 中执行 querystudent(grade)方法，按照传递 的年级查询所在级的研究生。 6.返回查询结果，保存在数据集 dataset_student 中。 7.cls_毕业资格审查.cs 将数据集 dataset_student 返回到 webfuwu_ 毕业资格审查.asmx。 8. webfuwu_毕业资格审查.asmx 将数据集 dataset_student 返回到毕 业资格审查.aspx。 9. 数据集 dataset_student 显示到浏览器。 顺序图有助于开发人员从时间的角度理解系统，而协作图可以更清 楚地明确类所具有的操作。 西安理工大学硕士学位论文 30 图 4-5 毕业资格审查用例实现协作图 顺序图和协作图有助于开发人员理解用例是如何实现的。然而，实 现系统需要的是具体的类。因此需要画出设计类的类图。这些类是实现 类的基础和依据。 系统设计 31 图 4-6 毕业资格审查用例实现类图 完成了对毕业资格审查用例的详细设计，最后就是对它的实现。系 统选用微软.net 平台进行业务实现。 使用 c#语言编写代码， 采用 asp.net 的 web 窗体进行界面开发，使得实现变得快捷高效。最后下图显示的系 统实现的页面： 学院办秘书进入系统，通过对本学院的当年毕业年度的研究生所在 级的选择，得到该年级所有在校研究生列表，查看每个研究生的成绩单、 答辩论文信息后，对满足毕业资格的研究生甄选，最后进行毕业生名单 的提交。 1、自动化学院办秘书选择将毕业在校研究生所在级 2002 级，得到 学生列表： 西安理工大学硕士学位论文 32 图 4-7 选择 2002 级将毕业在校研究生列表界面图 2、学院办秘书查看列表中某个待审核研究生的答辩论文信息： 图 4-8 查看某待审核研究生答辩论文信息界面图 3、学院办秘书提交满足毕业资格条件的毕业生名单： 系统设计 33 图 4-9 提交满足毕业资格条件的毕业生名单界面图 4.4 持久对象设计与实现 在研究生部毕业生信息系统开发中，后台的数据库采用关系数据库 管理系统 sql server 2000，而系统的分析与设计是面向对象的，因此在 数据库的设计过程中也应该考虑对象模型的结构和特点。 一般数据库设计多参照 ansl/sparc 关于数据库模式的提案。最接 近物理数据库的内部模式由 dbms 提供的 sql 描述。 概念模式由若干个 内部模式聚合而成，它是数据库用户规范的一些表的集合。外部模式是 从特定用户应用角度看待的数据库模式，从不同的应用出发对同一概念 模式可以给出多种不同的外部模式。 当外部应用系统以对象模型进行抽象时，从各个应用出发抽象出的 对象模型可以映射到数据库外部模式上。但是，外部模式只是概念模式 的子集，所以面向对象的数据库设计核心在于系统对象模型向数据库概 念模式的映射。在对象模型中，主要是对象类和类间关系到数据库概念 西安理工大学硕士学位论文 34 模式的映射。 1、对象的标识 对象是类的实例，一个对象之所以区别于另外一个对象在于它们的 属性值不完全相同，能够区别对象的最小属性或属性组就是对象标识(oi d)。对象标识将映射为表的主键。 2、对象类到表的映射 通常情况下，一个类可以映射到一个数据库表，类的属性映射为表 的列(并不一定每个属性都要映射列，因为不是每个属性都需要存储)。但 是，如果类中包含一对多关系是，一个类可以映射为多个表。 3、类间关系到表的映射 类之间有四种关系：关联、依赖、聚合和继承。类间关系到表的 映射主要是实体类向数据库中表的映射，由于这四种关系的各自特点不 同，向数据库的映射也不完全相同。依赖和聚合的映射比较简单，两个 依赖关系的类映射到表时，包含依赖的表中保存被依赖的表的主键；存 在聚合关系的两个类映射到表时，部分的表中保存整体的表的主键。关 联和继承关系向数据库表映射要复杂一些，下面详细讨论。 类之间的 关联有以下几种情况： 多对多关联，在实施多对多关联映射到表时， 除了两个类分别映射两个基本表之外，还应该映射一个关系表，关系表 中保存两个基本表的主键。 一对多关联， 一对多的两个类映射到表时， “多”表包含“一”表的主键。零或一对一关联，零或一对一的两个 类映射到表时， “零或一”表包含“一”表的主键。一对一关联，一对 一的两个类映射到表时，可以在任意的一个表中包含对方的主键。 按照上面的映射规则，研究生毕业信息系统部分的类映射到数据库 上的数据表如图 4-10 所示。从分析的结果来看，采用统一建模方法规划 出的数据库与应用信息工程方法规划的数据库基本是一致的。并且，统 一建模方法的结果也包含了子系统与外界的数据交换情况。 系统设计 35 图 4-10 研究生毕业信息系统数据库表结构 4.5 组件设计 经过系统软件设计和数据模型设计后，系统的所有逻辑软件元素都 西安理工大学硕士学位论文 36 设计完成了。下来要做的就是设计需要实现的物理软件单元，其中包括 源程序文件、数据库、软件组件等。本系统是完全基于组件技术的，系 统包含的所有类文件都分配在组件中，事先编译好供部署使用。 使用组件技术，不仅可以减小编译后软件单元的粒度，提高部署的 灵活性，还为软件的分布式部署带来了方便。在完成了这一步的设计后 就可以着手进行代码实现了。 在此仍仅对毕业管理子系统设计成果进行详细描述。 在实现时为逻辑 设计得到的每个类建立一个源程序文件保存代码。如：审查毕业资格类 程序保存在毕业资格审查类文件中。审查毕业资格类需要引用的组件和 命名空间的说明，可以保存在审查毕业资格类说明文件中，有的语言中 专门定义了这一文件，有的则和源程序保存在一个文件中，但设计时独 立说明是有益的。 在完成了类文件的定义和设计后，就可以将类文件分类分配到组件 中，以便编译打包为可执行代码实体。 本系统的分类规则为：按照子系统和子系统中的层次模型分组将类 文件进行打包。 毕业管理子系统业务规则层包含三个类文件：审查毕业资格_规则、 管理毕业生信息_规则、生成毕业上报数据_规则，和他们的说明文件， 就被分配到毕业管理子系统_规则组件中，如图 4-11 所示。在编译时，系 统将组件包含的文件打包，编译生成独立的毕业管理子系统_规则组件。 系统难点 37 图 4-11 毕业管理子系统_规则组件包含类文件结构图 图 4-12 中给出了整个系统包含的组件以及组件之间的依赖关系。我 们将系统分为前后台两部分，前台系统是研究生毕业信息系统的信息服 务系统，对学校其他用户发布收集信息的，后台系统是研究生毕业信息 管理系统，是研究生管理人员使用的应用系统，管理研究生教务数据。 由于统一了系统的前后台，往往会出现业务的重叠，所以我们采用一套 业务逻辑支持两套系统的表示层，实现了应用系统软件逻辑的共享。 研究生部毕业信息系统采用了 web service 技术结合前面设计软件体 系结构设计了应用系统的集成方案。我们选择了将前台系统的表示层部 署在非军事区中，这样前台系统就需要穿过防火墙访问内部数据，决了 数据库安全的问题。将其业务逻辑层和后台系统的表示层部署在研部内 部网络中。这样既解决了访问数据库的问题，又为后台系统提供了逻辑 服务。前台表示层都通过访问 web 服务连接业务逻辑组件，完成业务规 则处理和数据访问。后台表示层直接连接业务逻辑组件。这样就从逻辑 层将两个应用系统集成在了一起。整个系统共用数据服务组件和研究生 毕业信息数据库组件。 西安理工大学硕士学位论文 38 数据服务组件是经过系统设计过程， 将系统所有数据访问需求整理泛 化出的通用数据访问、操作组件，作为系统的数据服务层将应用系统和 数据库中间隔离，封装了系统直接访问数据库的操作，简化了应用系统 的开发。这个技术将在下一章介绍。 图 4-12 研究生毕业信息系统组件