UML成绩管理系统

软件系统建模与软件系统建模与 UMLUML 课课 程程 设设 计计 报报 告告 设计题目设计题目成绩管理系统 院院系系 专专业业 班班级级 学学号号 姓姓名名 指导教师指导教师 设计地点设计地点 开课时间开课时间 常熟理工学院计算机科学与工程学院制 - 1 - 学生姓名学生姓名成绩成绩 评语评语 指导教师（签名）指导教师（签名） 年年月月日日 - 2 - 目录目录 1. 设计目的和任务 2 2. 开发环境 . 2 2.1 硬件环境 2 2.2 软件环境 3 3.设计题目 . 3 3.1 题目名称 3 3.2 题目详细描述 .3 3.3 功能要求 3 4. 相关技术及知识点 .4 4.1 用例建模 . . 4.2 用例的定义 . 4.3 构造用例图的步骤 . 4.4 RUP 的核心工作流 . 4.5 概念模型 . 4.6 概念模型作用 . 4.7 类图. 4.8 类的三个层次 . 4.9 如何建立关联 . . . 4.10 系统行为 4.11 图 4.12 契约. 4.13 协作图 . 4.14 三层结构的优势 5. 面向对象分析与设计 .7 5.1 用例图 . . . . . . . . . 5.2 概念模型 . . . . . . . . . 5.3 系统类 . . 5.4 契约. . . 5.6 系统类图 . 5.7 状态图 . . . 5.8 系统组件图 . 6. 双向工程 7. 总结.23 8. 参考资料 . 23 - 3 - 成绩管理系统成绩管理系统 1.1.设计目的和任务设计目的和任务 成绩管理系统以计算机为工具，通过成绩管理所需的信息管理，把管理人员从 繁琐的数据计算处理中解脱出来，使其有有更多的精力来从事成绩管理的研究工作， 从而全面提高教学质量。 1.11.1 设计目的设计目的 要求本系统具有以下功能 1）为每个使用系统的人员设置权限。只有通过权限验证的人才能使用系统。 2）学生可以使用该系统查询所学课程的成绩。 3）教师使用该系统完成学生成绩的录入、修改、显示和打印。 4）管理员使用系统输入学生信息、教师信息、班级信息和课程信息。 1.21.2 设计任务设计任务 在明确系统功能点后，按授课要求，请用面向对象分析设计的方法设计系统， 参考 RUP 的流程，依次得出系统的参与者、用例图、概念模型、系统类并定义系统 类操作的契约、 协作图（请考虑三层架构的设计方式） 、 得出系统的类图、 数据库表， 对得出的各种UML 图需要进行文字描叙。 2.2.开发环境开发环境 1.1 硬件环境 计算机。 1.2 软件环境 RathionalRose 。 3.3.设计题目设计题目 3.13.1 题目名称题目名称 成绩管理系统 3.23.2 题目详细描述题目详细描述 成绩管理系统是一个基于成绩查询的系统，不同类型的用户在系统中有不同的权限。主 要有三种用户 学生可以查询成绩。 教师主要负责成绩的录入和查询。 管理员主要负责将成绩信息增加，修改，删除，并导入数据库。 3.33.3 功能要求功能要求 4 （（1 1）系统总体的功能需求）系统总体的功能需求 学生成绩管理系统主要完成对学生在校成绩信息的管理, 并能够将所需要的数据按照表格 形式导出。该系统可以完成对学生 成绩的录入、 查询, 也可以实现学生成绩的统计及打印等功能。 通过对系统的分析, 可得出 系统功能图 如图 。 （（2 2）系统边界分析）系统边界分析 该系统供学校教师与学生使用，教师可以录入成绩，管理并维护数据；学生没 有管理数据的权限，只能进行查询。 （（3 3）系统功能性需求分析）系统功能性需求分析 对于教师 管理员 ，具有以下几种功能 ①学生个人信息管理 查询、添加、修改、删除、打印学生个人信息 ②学生成绩管理 查询、添加、修改、删除、打印学生考试成绩 对于学生，具有以下几种功能 查询个人信息，查询、打印、报错个人成绩 （（4 4）系统功能性需求分析）系统功能性需求分析 性能需求 开发系统性能稳定，不应出现操作上的失误而引起的系统关闭等。 安全性需求 不同权限的操作人员只能操作某些功能，不可越权操作 人机交互需求 操作人性化，用户比较舒适的使用系统，不可难于理解和复杂; 系统观感 要求界面颜色搭配合理，不能单调或者过于绚丽； 经济效益 要求开发周期不能超过半年，合理管理开发过程，不得造成浪费. 4.4. 相关技术及知识点相关技术及知识点 4.14.1 用例建模用例建模 用例建模是需求工程的一种形式，是抽取和文档化需求的补充方法 相对于“传统” SRS 方法 用例是 Jacobson 在面向对象的软件工程中提出的，但它实际上是独立于面向对 象的。 典型用例建模方法 找出系统边界。 找出参与者。 找出用例 包括说明用例，创建场景 4.24.2 用例的定义用例的定义 5 定义由系统执行的一个动作序列，并能产生可观测的结果值给特定的角色。 如 从 ATM 机提取现金； 定购一个商品； 从学校选课系统注册选课； 从文本编辑器中检查一个文档的拼写错误； 用例命名 状语＋）动词＋（定语＋）宾语 4.34.3 构造用例图的步骤构造用例图的步骤 1.确定系统的上下文 1.1确定参与者与它们的责任； 1.2确定用例，即确定带有某种目的或产生特定结果的系统行为。 2.对参与者和用例进行权衡，以便精化模型，例如拆分和合并定义。 3.衡量用例以找出包含关系。 4.衡量用例以找出扩展关系。 5.对参与者和用例进行研究，查找是否存在泛化关系。 4.4 RUP4.4 RUP 的核心工作流的核心工作流 （1）6 个核心工程工作流 需求工作流 分析和设计工作流 实现工作流 测试工作流 分发工作流 （2）3 个核心支持工作流 项目管理工作流 配置和变更控制工作流 环境工作流 4.54.5 概念模型概念模型 概念模型展现了问题域中有意义的概念， 是 OOA 中要得到的最重要的制品。 是真实世界中各个事物的代表，而不是软件中各个构件的代表。 概念模型包括 1、一组概念； 6 2、概念之间的关联； 3、概念的属性； 4.64.6 概念模型作用概念模型作用 概念模型的作用将问题域空间分解成小的单元（概念）；帮助澄清领域中 的术语和词汇（有哪些重要术语、以及术语之间的关系如何）。 4.74.7 类图类图 类图描述了系统中的类及其相互之间的各种关系。 类之间的关系表示了对象之间的通信能力。 类之间有三种关系 4.84.8 类的三个层次类的三个层次 －Conceptual 概念层。描述问题域中的概念，不考虑或很少考虑实现上的细 节－No Software 。只考虑属性，在分析阶段使用。 －Specification 说明层。 Looking into Software,butonly interface of the software, not the implementation. Only type, not class。增加操作定义，在 设计阶段使用。 －Implemen