江苏大学计算机科学与通信工程学院面向对象建模技术课件 第2章.ppt

江苏大学计算机科学与通信工程学院面向对象建模技术课件 第2章.ppt

  1. 1、本文档共48页,可阅读全部内容。
  2. 2、有哪些信誉好的足球投注网站(book118)网站文档一经付费(服务费),不意味着购买了该文档的版权,仅供个人/单位学习、研究之用,不得用于商业用途,未经授权,严禁复制、发行、汇编、翻译或者网络传播等,侵权必究。
  3. 3、本站所有内容均由合作方或网友上传,本站不对文档的完整性、权威性及其观点立场正确性做任何保证或承诺!文档内容仅供研究参考,付费前请自行鉴别。如您付费,意味着您自己接受本站规则且自行承担风险,本站不退款、不进行额外附加服务;查看《如何避免下载的几个坑》。如果您已付费下载过本站文档,您可以点击 这里二次下载
  4. 4、如文档侵犯商业秘密、侵犯著作权、侵犯人身权等,请点击“版权申诉”(推荐),也可以打举报电话:400-050-0827(电话支持时间:9:00-18:30)。
查看更多
* * * * * * * * * * * * * * * Place Order 下订单 Request Catalog 申请目录 * * * * * * * * * * * * * 泛化、包含与扩展关系的区别 2.5 用例建模 建模步骤 确定系统涉及的总体信息 确定系统的参与者 确定系统的用例 构造用例模型 下面以单机版的图书管理系统为例,说明建模过程 2.5.1 确定系统涉及的总体信息 书籍借出处理 书籍归还处理 查看借阅者的借阅信息 借阅者信息的维护 图书管理员信息的维护 图书信息的维护 2.5.2 确定系统的参与者 首先分析系统所涉及的问题领域和系统运行的主要任务: 分析使用该系统主要功能部分的是哪些人。 谁将需要该系统的支持以完成其工作。 系统的管理者与维护者。 详细需求列表 系统可以完成学生借书和还书请求 系统允许学生浏览借阅信息 如果学生超期未还,系统生成一个超期罚款信息 图书信息需要维护 学生信息需要维护 图书管理员信息需要维护 系统需要维护 2.5.2 确定系统的参与者 2.5.2 确定系统的参与者 图书馆管理系统的参与者: 图书管理员 系统维护者 2.5.3 确定用例与构造用例模型 1. 图书管理员的用例 2. 系统管理员的用例 1. 图书馆管理员的用例 登录 书籍借阅 书籍归还 查看借阅信息 2. 系统管理员的用例 登录 维护借阅者信息 维护借阅信息 维护图书信息 维护图书管理员信息 对用例进行细化 提取公用部分 添加缺少用例 绘制用例图 绘制用例图是一个迭代过程,不必一次就列出完整的用例模型图。 2.5.3 确定用例与构造用例模型 图书管理员构造用例模型 用例细化 提取公用部分 超期处理 显示借阅信息 添加缺少用例 修改密码 图书管理员用例 构造用例模型-系统管理员 用例细化 使用泛化方式细化用例 提取公用部分 无 添加缺少用例 维护图书标题用例 系统管理员用例 习题 P40 分析题1 注意: 对于公共部分和可选部分,可以提取出来构成独立用例 对于并列的功能,可以使用泛化用例 对于顺序的功能,不必再分化成独立的用例 练习:网络教学系统的需求分析 系统功能需求 数据信息管理模块 基本业务模块 信息浏览、查询模块 练习:网络教学系统功能需求 系统的功能需求主要包括以下几个方面: 学生可以登录网站浏览课程信息、查找和下载课件。 教师可以登录网站发布和更新课程信息、上传课件文件。 系统管理员负责维护教师和学生的账号。 系统管理员负责建立或者删除课程,并将课程指定给一位教师管理,一位教师可以管理多个课程。 对该需求进行用例建模 本章完 * * * * * * * * * * * * * * 面向对象建模技术 软件工程系 林 琳 * 第2章 用例图 人们在进行软件开发时,无论是采用面向对象方法还是传统方法,首先要做的就是了解需求。在进行需求分析时,使用用例图可以更好描述系统应具备什么功能。用例图由开发人员与用户经过多次商讨而共同完成,软件建模的其他部分都是从用例图开始的。 * 本章学习要点: 用例图的组成 理解泛化 理解用例之间的关系 对用例进行描述 绘制用例图 * 2.1 用例图的构成 用例图用于定义系统的功能需求,它描述了系统的参与者与系统提供的用例之间的连接关系。这里的参与者可以人,也可以另一个系统。用例图仅从参与者使用系统的角度描述系统中的信息。下图描述了一个学生成绩管理系统的用例图。 用例图包含四个基本元素: 用例(Use Case) 参与者(Actor) 系统(System) 关系(Relation) 关联关系(Association) 包含关系(Include) 扩展关系(Extend) 泛化关系(Generalization) 2.1 用例图的构成 * 2.1.1 系统 系统是为用户执行某类功能的一个或多个软件构件。系统的边界用来说明用例图应用的范围。 准确定义系统的边界并不总是很容易的,因为有些情况下,严格地划分哪些任务是由系统完成,而哪些是由人工或其他系统完成是很困难的。 一般的作法是,先识别出系统的基本功能,然后以此为基础定义一个稳定的、精确定义的系统架构,以后再不断地扩充系统功能,逐步完善系统。这样做可以避免由于系统太大,需求分析不易明确,从而导致浪费大量的开发时间。 系统用一个方框表示,可以省略。 2.1.2 参与者 系统外部的一个实体。 参与用例的执行过程。 参与者通过向系统输入或者系统要求参与者提供某种信息来进行交互。 由参与用例时所担当的角色来表示,命名时以所扮演的角色命名。 每个参与者可以参与一个或多个用例。 2.1.2 参与者 参与者的种类: 系统用户 与所建造的系统交互的其他系统 一些可

文档评论(0)

ormition + 关注
实名认证
内容提供者

该用户很懒,什么也没介绍

1亿VIP精品文档

相关文档