第2章 软件需求-2 软件工程课件.ppt

软件需求-2面向对象的分析方法 2.3 面向对象的需求分析方法 面向对象技术 面向对象分析概述 建立用例模型 建立对象模型 建立动态模型 建立数据模型 面向对象的思想最初出现于挪威奥斯陆大学和挪威计算机中心共同研制的 Simula 67 语言中，随着 Smalltalk---76 和 80 语言的推出，面向对象的的程序设计方法得到了比较完善的实现。 如今面向对象的技术已成为软件开发的一种主要方法。 软件开发的本质 问题空间—软件系统所涉及到的应用领域和业务范围（现实世界）。 解空间—用于解决某些问题的软件系统。 5、多态性和动态绑定 多态性(Polymorphism)是指相同的操作或函数、过程作用于不同的对象上并获得不同的结果。 即相同的操作的消息发送给不同的对象时，每个对象将根据自己所属类中定义的操作去执行，产生不同的结果。 例如： “绘图”操作，作用在“椭圆” 和“矩形” 上，画出不同的图形。 OOA 的基本任务 运用面向对象的方法，对问题域和系统责任进行分析和理解。 找出描述它们的类和对象。 定义其属性和操作，及其结构、静态联系和动态联系。 2.3.2 面向对象分析概述 面向对象分析的 3 个模型 用例模型：用例和场景表示的功能模型； 对象模型：用类和对象表示的静态模型； 交互模型：由状态图和顺序图表示的动态模型。 面向对象分析概述 对象模型的5个层次 Coad Yourdon 提出，复杂问题(大型系统)的对象模型应该由下述5个层次组成：主题层(也称为范畴层)、类-对象层、结构层、属性层和服务层，实际建模中不必严格遵循这样一个顺序，而是反复细化的过程。 说明 以下讨论面向对象分析的具体建模方法 实际建立的模型，是用 UML 进行描述的 书中将 UML 的介绍单独列为一章 我们课中将该章的内容，分散到相关各章，结合相应内容进行介绍。 目前先暂时转到我们 PPT 的第三章。 2.3.3 建立用例模型 用例模型(Use case model)描述外部执行者(Actor)所理解的系统功能。即待开发系统的功能需求。 它驱动了需求分析之后各阶段的开发工作,还被用于验证和检测所开发的系统, 影响 UML 的各个模型。 用例模型由若干个用例图构成，用例图中主要描述执行者和用例之间的关系。 在 UML 中，构成用例图的主要元素是用例和执行者及其它们之间的联系。 建立用例模型 建立用例模型的过程 (1) 确定业务参与者──标识目标系统将支持的不同类型的用户，可以是人、事件或其他系统。 (2) 确定业务需求用例──参与者需要系统提供的完整功能。 (3) 创建用例图──标识参与者与用例之间、用例与用例之间的关系。 例: 选课系统 给教师分配课程和学生注册课程 在每个学期选课开始之前，系统管理员需要对系统中的教师信息、课程信息和学生信息进行维护。 学期结束后，将本学期成绩归档到学籍档案系统。 学生 登录系统后会得到本学期将要开设的课程目录。每门课程包含的信息有开课系别、教师、上课时间、教室、容纳的学生数量和学生选择课程的先决条件。 当学生选择了一门课程后，系统需访问学籍档案系统，查询是否符合选课的先决条件 。如果不符合，系统给出提示信息。 每个学期有一段时间让学生可以改变计划，学生可以在这段时间内访问联机系统以增选课程或退选课程。 教师 可以访问在线系统，查看将要教授哪些课程和每门课程有哪些学生报名。 课程考试结束后可以提交成绩。 系统可以生成带有成绩分布统计结果的成绩单。 1. 确定业务参与者 通过关注系统的业务参与者，可以将重点放在如何使用系统，而不是如何构造系统上。 有助于进一步明确系统的范围和边界。 当系统比较庞大和复杂时，要搞清楚系统的需求往往比较困难，通过明确参与者，可以针对参与者确定系统需求，有助于保证系统需求的完整性。 1. 确定业务参与者 可通过以下资料来确定系统的参与者： 标识系统范围和边界的环境图； 现有系统（如果有的话）的文档和用户手册； 项目会议和研讨会的记录； 现有的需求文档、工作手册等。 1. 确定业务参与者 还可以通过以下问题，明确系统的参与者： 谁或者什么为系统提供输入？ 谁或者什么接收系统的输出？ 需要与其他系统连接的接口吗？ 是否存在在预定的时间自动触发的事件？ 谁将维护系统中的信息？ 1. 确定业务参与者 从选课系统的需求描述中，可以确定 4 类参与者： 学生（Student） 教师（Teacher） 系统管理员（Administrator） 学籍档案系统（Archive System） 2. 确定业务需求用例 用例 (use case) 从本质上讲，一个用例是用户与计算机之间的一次典型交互作用。 在 UML 中，用例被定义成系统执行的一系列动作（功