软件工程第五章面向对象分析与设计PPT课件
合集下载
软件工程 面向对象分析与设计PPT课件
面向过程
围绕功能，函数，数据公用，兼顾很多细节 系统规模大、数据多、操作烦杂，程序员难以应付 厂长，直接指挥每一个工人选用材料生产汽车
面向对象
面对的是一个个对象 实际上，每一组数据有特定的用途，一组操作调用一组数据，
将这组数据和操作代码，封装成一个对象，与外界相对隔离， 相对独立 厂长－车间1（发动机）车间2（轮胎）车间3（底盘）…… 类，对象，对象间接送消息，完成任务 降低难度，减少出错机会
面向对象分析的基本过程
面向对象分析法体现 在过程上的特点：不 强调活动的顺序，允 许各种活动的交替、 回溯进行
定义use case
发现对象
原
详
型 开
定义属性及服务
细 说
发
明
建立结构与连接
划分主题
建立交互图
1.23
© 2009 by Duym
Software Engineering
面向过程(po)与面向对象(OO)
利用自己已建立的类，或别人的放在类库中的类，缩短开 发周期
1.14
© 2009 by Duym
Software Engineering
2.5多态（polymorphism）
一班、二班、三班 铃声响了，走进不同的教室，上不同的课程
向不同的对象，发出相同的消息，执行不同的 操作
鼠标双击文件，exe文件则运行该文件，doc文件则运行 word打开该文档
对象模型是客观世界对象、属性以及对象彼 此间关系的抽象表达，描述了系统的静态结 构
表示方法
类与对象 结构与连接
一般特殊关系，分类关系，归纳关系，继承 整体部分关系，组成关系 实例连接，对象间属性之间的静态联系 消息连接，对象行为之间的动态联系
面向对象分析及设计第5章软件开发的方法学PPT课件
6
5.2.1 需求
第5章 软件开发的方法学
需求包括：
◦ 业务需求：反映了组织机构或客户对系 统、产品高层次的目标要求
◦ 用户需求：描述了用户使用产品必须要 完成的任务
◦ 功能需求 ：定义了开发人员必须实现的 软件功能，使得用户能完成他们的任务， 从而满足了业务需求。
◦ 非功能需要：对系统性能、界面等的要 求
规范：对软件开发过程的清晰、明确的 描述，指出软件组件的用法、如何正确 操作。
规范是按合同设计的、至关重要的 底层规则
5.2.5 实现
实现：编写代码，形成子系统，各种子 系统协同工作，形成整个系统
2020/7/28
9
5.2.6 测试
第5章 软件开发的方法学
测试：根据系统需求验证系统的实现 包括单元测试、集成测试和移交测试
方法学涉及软件开发、阶段管理、 资源管理、规划、调度和其他管理 任务的建议或技术
优秀的、适用范围广的方法学是成 熟软件业的基础。
2020/7/28
5
第5章 软件开发的方法学
5.2 软件开发中的经典阶段
① 需求 ② 分析 ③ 设计 ④ 规范
⑤ 实现 ⑥ 测试 ⑦ 部署 ⑧ 维护
2020/7/28
5.2.7 部署
部署：将硬件和软件交付给最终用户, 并提供手册和培训材料
2020/7/28
10
5.2.8 维护
第5章 软件开发的方法学
维护：包括改正性维护、完善性维护和 适应性维护
5.2.9 关键问题
通过一些关键问题可以帮助了解、记 住个软件开发阶段及其目的。（略）
2020/7/28
11
第5章 软件开发的方法学
2020/7/28
《面向对象分析 》课件
代码可读性
面向对象分析是逐步抽象、逐步分类的过程， 程序代码更加具有可读性，并可避免重复代 码创建
面向对象分析的流程
1
需求定义
收集并分析业务需求，根据需求建立初步模型。
2
形成模型
在初步模型的基础上，进行建模、分析、设计和验证，形成正式模型。
3
评价和完善
评估模型的质量并进行优化，最后形成完整、准确的模型。
领域建模
1
领域建模的流程
2
通过客户需求、市场环境、组织机构
等多方面考虑，建立基础识别原则，
全面地把控领域的各种可能性。
3
领域模型的符号与构建方法
4
领域模型是可以描述系统所分析的需 求的，采用实体、边界、控制等几个 方面的关系模型，以透视实体、边界、
记录等三个信息进行分析。
领域建模的定义
领域建模是对业务领域进行分析和建 模，从而达成对业务领域的深刻理解 的过程。
对象与类
对象的三个主要特征
对象是系统中一个具体实体，具备身份、状态 和行为三个主要特征，是面向对象分析的基本 概念。
类的定义与实现
类是具有相同属性和行为的对象集合，是对对 象的相似性的一种抽象，具体了相同概念的特 征和关系。
类的关系
类的关系包括继承、聚合、组合、依赖、关联 和实现，是所有系统元素之间的关系件将帮助你深入了解面向对象分析的流程和方法，掌握开发中的应用 技巧。
什么是面向对象分析？
深入理解业务需求
面向对象分析是一种针对业务需求的软件开发 方法，通过抽象出各个业务实体及其属性及行 为关系，建立起软件模型，实现对业务的深度 理解。
以对象为核心
面向对象分析是基于对象的思想进行软件需求 分析和设计，将对象作为核心概念，以对象之 间的关系为架构进行软件分析与设计。
面向对象分析是逐步抽象、逐步分类的过程， 程序代码更加具有可读性，并可避免重复代 码创建
面向对象分析的流程
1
需求定义
收集并分析业务需求，根据需求建立初步模型。
2
形成模型
在初步模型的基础上，进行建模、分析、设计和验证，形成正式模型。
3
评价和完善
评估模型的质量并进行优化，最后形成完整、准确的模型。
领域建模
1
领域建模的流程
2
通过客户需求、市场环境、组织机构
等多方面考虑，建立基础识别原则，
全面地把控领域的各种可能性。
3
领域模型的符号与构建方法
4
领域模型是可以描述系统所分析的需 求的，采用实体、边界、控制等几个 方面的关系模型，以透视实体、边界、
记录等三个信息进行分析。
领域建模的定义
领域建模是对业务领域进行分析和建 模，从而达成对业务领域的深刻理解 的过程。
对象与类
对象的三个主要特征
对象是系统中一个具体实体，具备身份、状态 和行为三个主要特征，是面向对象分析的基本 概念。
类的定义与实现
类是具有相同属性和行为的对象集合，是对对 象的相似性的一种抽象，具体了相同概念的特 征和关系。
类的关系
类的关系包括继承、聚合、组合、依赖、关联 和实现，是所有系统元素之间的关系件将帮助你深入了解面向对象分析的流程和方法，掌握开发中的应用 技巧。
什么是面向对象分析？
深入理解业务需求
面向对象分析是一种针对业务需求的软件开发 方法，通过抽象出各个业务实体及其属性及行 为关系，建立起软件模型，实现对业务的深度 理解。
以对象为核心
面向对象分析是基于对象的思想进行软件需求 分析和设计，将对象作为核心概念，以对象之 间的关系为架构进行软件分析与设计。
面向对象分析与设计-分析-ppt文档
？
《对象技术词典》：
1．对一个系统或者一个应用的一种单一的使用方式所进行的描述。
2．关于单个参与者在与系统的对话中所执行的处理的行为陈述序列。
UML：
？
对系统在与它的参与者交互时所能执行的一组动作序列（包括其变体）
的描述。
本书的定义：
用况是对参与者使用系统的一项功能时所进行的交互过程 的描述，其中包含由双方交替执行的一系列动作。
if 货架商品数低于下限 then call 通知上货
end if； 计算本种商品总价并打印编号、 名称、数量、单价、总价； 总价累加到应收款总数； end for； 打印应收款总数； 输入顾客付款数； 计算应找回款数， 打印付款数及找回款，
应收款数计入账册。
如何定义用况
针对单个用况的描述策略： 把自己当作参与者，与设想中的系统进行交互。考虑： 交互的目的是什么？需要向系统输入什么信息？希望由 系统进行什么处理并从它得到何种结果？把上述交互过 程描述出来 。
考虑问题的思路：把系统看作一个黑箱，看它对外部的 客观世界发挥什么作用，描述其外部可见的行为。
系统是由一条 边界包围起来
的未知空间
系统边界以外 是与系统进行 交互的参与者
只通过有限 的几个接口 与外部交互
把内外交互情况描 述清楚，就确切地 定义了系统的需求
5.3 系统边界与参与者
系统边界：一个系统所包含的所有系统成分与系统以外 各种事物的分界线。 系统：被开发的计算机软硬件系统，不是指现实系统。 系统成分：在OOA和OOD中定义并且在编程时加以实 现的系统元素——对象
汽车
钟表
职员
起重机 飞机
奖杯 操作员
天平 楼房
如何发现参与者 ——考虑人员、设备、外系统
面向对象的分析和设计.ppt
23
子系统的设计准则是： (1) 子系统应具有定义良好的接口，通过接口 和系统的其它部分通信； (2) 除了少数的“通信类” 外，子系统中的类 应只和该子系统中的其它类协作； (3) 子系统的数量不宜太多； (4) 可以在子系统内部再次划分，以降低复杂 性。
24
2) 标识问题本身的并发性，并为子系统分配 处理器 通过对对象--行为模型的分析，可发现系 统的并发性。如果对象（或子系统）不是同时 活动的，则它们不需并发处理，此时这些对象 （或子系统）可以在同一个处理器上实现。反 之，如果对象（或子系统）必须对一些事件同 时异步地动作，则它们被视为并发的，此时， 可以将并发的子系统分别分配到不同的处理器， 或者分配在同一个处理器，而由操作系统提供 并发支持。
15
5. 多态性（polymorphism） 多态性是指同一个操作作用于不同的对象 上可以有不同的解释，并产生不同的执行结 果。例如“画”操作，作用在“矩形”对象 上，则在屏幕上画一个矩形，作用在“圆” 对象上，则在屏幕上画一个圆。也就是说， 相同操作的消息发送给不同的对象时，每个 对象将根据自己所属类中定义的这个操作去 执行，从而产生不同的结果。
16
6. 动态绑定（dynamic binding） 动态绑定是指在程序运行时才将消息所请 求的操作与实现该操作的方法连接起来。 传统的程序设计语言的过程调用与目标 代码的连接（即调用哪个过程）放在程序运 行前（即编译时）进行（称为静态绑定）， 而动态绑定则是把这种连接推迟到运行时才 进行。 动态绑定是一种在运行时确定被执行代 码的技术。
模型元素指模型中的实体以及实体间相互连接的关系
类 属性 操作 主动类 属性 操作 对象：类 属性 操作
用况
结点
状态
子系统的设计准则是： (1) 子系统应具有定义良好的接口，通过接口 和系统的其它部分通信； (2) 除了少数的“通信类” 外，子系统中的类 应只和该子系统中的其它类协作； (3) 子系统的数量不宜太多； (4) 可以在子系统内部再次划分，以降低复杂 性。
24
2) 标识问题本身的并发性，并为子系统分配 处理器 通过对对象--行为模型的分析，可发现系 统的并发性。如果对象（或子系统）不是同时 活动的，则它们不需并发处理，此时这些对象 （或子系统）可以在同一个处理器上实现。反 之，如果对象（或子系统）必须对一些事件同 时异步地动作，则它们被视为并发的，此时， 可以将并发的子系统分别分配到不同的处理器， 或者分配在同一个处理器，而由操作系统提供 并发支持。
15
5. 多态性（polymorphism） 多态性是指同一个操作作用于不同的对象 上可以有不同的解释，并产生不同的执行结 果。例如“画”操作，作用在“矩形”对象 上，则在屏幕上画一个矩形，作用在“圆” 对象上，则在屏幕上画一个圆。也就是说， 相同操作的消息发送给不同的对象时，每个 对象将根据自己所属类中定义的这个操作去 执行，从而产生不同的结果。
16
6. 动态绑定（dynamic binding） 动态绑定是指在程序运行时才将消息所请 求的操作与实现该操作的方法连接起来。 传统的程序设计语言的过程调用与目标 代码的连接（即调用哪个过程）放在程序运 行前（即编译时）进行（称为静态绑定）， 而动态绑定则是把这种连接推迟到运行时才 进行。 动态绑定是一种在运行时确定被执行代 码的技术。
模型元素指模型中的实体以及实体间相互连接的关系
类 属性 操作 主动类 属性 操作 对象：类 属性 操作
用况
结点
状态
面向对象的设计与分析课件
WENKU DESIGN
2023-2026
END
THANKS
感谢观看
KEEP VIEW
WENKU DESIGN
WENKU DESIGN
WENKU
REPORTING
https://
PART 01
面向对象的基本概念
对象与类
对象
现实世界中的事物或概念在面向对象 编程中的表示。每个对象都有其属性 （状态）和方法（行为）。
类
对象的抽象，定义了一组具有相同属 性和方法的对象的共同特征。类是对 象的模板或蓝图。
封装与继承
封装
将对象的属性和方法封装在一起，隐藏对象的内部实现细节，只通过对象的方法来访问其属性。
目的
提高类的可维护性和可复用性，降低类之间的耦 合度。
示例
一个表示用户的类，只负责存储和提供用户数据， 不包含其他如登录、注册等操作。
开闭原则
定义
软件实体应该对扩展开放，对修改封闭。即软件实体应该通过扩 展来实现变化，而不是通过修改已有的代码来实现变化。
目的
提高软件的可维护性和可复用性，降低修改代码的风险。
目的
降低类之间的耦合度，提高系统的可维护性和可复用性。
示例
使用接口或抽象类来实现高层模块和低层模块之间的依赖关系， 而不是直接依赖于具体实现类。
PART 03
面向对象的分析方法
识别对象与类
01
确定问题域中的实 体
通过分析问题背景，识别出问题 域中的实体，如人、事物、组织 等。
02
抽象出对象的属性 和行为
VS
继承的实现
继承的实现方式因编程语言而异。在Java 中，子类通过使用关键字"extends"来继 承父类。在C中，子类通过在类名前使用 冒号":"来实现继承。
软件工程第五章面向对象分析与设计PPT课件
记录全部访谈内容 ④ 安排补充会议 访谈之后 ⑤ 根据标准模版撰写软件需求规格说明（SRS），
打客户需求草稿 ⑥ 通过电子邮件征求客户意见
对于不同类型的应用，用例方法是一种获取和 表达需求的有效方法。
某些需求需要通过数据流图或状态图与用户沟 通。
5.1.2 描述客户需求
需求可以看成是应用与应用的外部代理（如用户） 之间的交互。可利用用例作为表达工具。
3) 标识用例 当双方确定了一组场景后，开发人 员从该场景抽象出一组用例，描述所有可能的 情况。用力表达了系统的范围。
4) 求精用例 细化每一个用例。引入带有出错处 理或带有异常处理的用例，描述系统的行为， 保证需求的描述是完全的。
5) 标识用例之间的关系 描述用例之间的依赖关 系，提取相同功能，建立用例模型。
2. 访谈用户代表 识别各种需要与要求 使用工具帮助表达用户需求 绘制GUI草图 确定硬件环境
请用户评审
3. 用标准文档格式撰写客户需求
4. 核查用户需求 用户批准后
5. 构建详细需求（分析建模）
5.1.1 与用户交互
1) 需求的来源 不同类型应用能从人员处获取需求的比例:
不受限制的
应 用 的 类 型
馆藏图书（对象）的状态图
在架 报废
注销
丢失
出借
返还
上架
损坏
借出
修补
丢失
丢失
图书管理员借书操作的状态图
login （登录）
预约图书
借书
reserve
borrow
（预约）
（借阅）
检验图书 检验读者
借书
findTitle findBorrower （检索图书） （查找借阅者）
第5章面向对象软件设计PPT共33页
第5章面向对象软件设计
11、用道德的示范来造就一个人，显然比用法律来约束他更有价值。—— 希腊
12、法律是无私的，对谁都一视同仁。在每件事上，她都不徇私情。—— 托马斯
13、公正的法律限制不了好的自由，因为好人不会去做法律不允许的事 情。— 15、像房子一样，法律和法律都是相互依存的。——伯克
31、只有永远躺在泥坑里的人，才不会再掉进坑里。——黑格尔 32、希望的灯一旦熄灭，生活刹那间变成了一片黑暗。——普列姆昌德 33、希望是人生的乳母。——科策布 34、形成天才的决定因素应该是勤奋。——郭沫若 35、学到很多东西的诀窍，就是一下子不要学很多。——洛克
11、用道德的示范来造就一个人，显然比用法律来约束他更有价值。—— 希腊
12、法律是无私的，对谁都一视同仁。在每件事上，她都不徇私情。—— 托马斯
13、公正的法律限制不了好的自由，因为好人不会去做法律不允许的事 情。— 15、像房子一样，法律和法律都是相互依存的。——伯克
31、只有永远躺在泥坑里的人，才不会再掉进坑里。——黑格尔 32、希望的灯一旦熄灭，生活刹那间变成了一片黑暗。——普列姆昌德 33、希望是人生的乳母。——科策布 34、形成天才的决定因素应该是勤奋。——郭沫若 35、学到很多东西的诀窍，就是一下子不要学很多。——洛克
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
2. 访谈用户代表 识别各种需要与要求 使用工具帮助表达用户需求 绘制GUI草图 确定硬件环境
请用户评审
3. 用标准文档格式撰写客户需求
4. 核查用户需求 用户批准后
5. 构建详细需求（分析建模）
5.1.1 与用户交互
1) 需求的来源 不同类型应用能从人员处获取需求的比例:
不受限制的
应 用 的 类 型
应用受到的限制越少，能从人们那里获得的需求 比例越大。
2) 识别利益相关者（stakeholder）
对项目承担风险和享有利益的人即为利益相关者。 他们是应用的“客户”。如公司高层、项目经理、 最终用户、系统开发人员等。
不同利益相关者之间的利益冲突会导致需求不 一致。如果需求冲突不能调和，项目就会陷入 困境，最后往往会被取消。
用例描述了系统外的参与者（Actor）与应用之 间的交互情况。主要注重用户对系统的看法。
描述客户需求的过程如下：
1) 标识参与者 标识目标系统将支持的不同类型 的用户，可以是人、事件或其他系统。
2) 标识场景 用场景描述目标系统典型功能的活 动细节，并与用户沟通，加深开发人员对应用 领域的理解。
括添加、修改、删除馆藏图书信息
g) MaintainBookInfo：维护流通图书信息，包括 添加、修改、删除流通图书信息
一旦系统分析人员对该领域有了充分了解，就可 以建立一个业务模型，描述用户的业务过程，确 定用户的初始需求。然后通过迭代，更深入了解 应用领域，回过头来推敲业务模型。导出用户可理解的系统规格说 明。
开发用户需求的典型过程
1. 识别用户需求
没有专业的系统分析人员，用户很难了解到需要 开发什么相关信息和功能；另一方面，没有与用 户的交流，系统分析人员也很难弄清客户真正需 要什么。
发现用户需求的过程称为需求获取。一旦提出了 最初的需求，进一步推敲、细化和扩充的过程称 为分析。
需求获取的第一步是理解应用领域，即目标软件 的应用环境。如银行、电信公司、书店等。
3) 标识用例 当双方确定了一组场景后，开发人 员从该场景抽象出一组用例，描述所有可能的 情况。用力表达了系统的范围。
4) 求精用例 细化每一个用例。引入带有出错处 理或带有异常处理的用例，描述系统的行为， 保证需求的描述是完全的。
5) 标识用例之间的关系 描述用例之间的依赖关 系，提取相同功能，建立用例模型。
软件工程
第五章 面向对象分析与设计
5.1 需求获取 5.2 面向对象分析 5.3 面向对象设计 5.4 系统设计 5.5 对象设计
整体 概述
一 请在这里输入您的主要叙述内容
二
请在这里输入您的主要 叙述内容
三 请在这里输入您的主要叙述内容
2
5.1 需求获取
需求获取的目标是确定用户“需要”什么样的软 件产品，就是说，新的软件必须能够做什么。
完整的客户要求应当记录在需求文档的“概述” 部分。但需求中还有一些问题需要由系统分析 人员与客户商量，以明确这些需求。
例如游戏是否只允许玩家扮演一个角色还是可 以同时控制多个人物？当两个人相遇时会发生 什么事情？游戏是否可以联网对战等。
4) 访谈和文档记录
大部分需求获取是人与人沟通的活动，这些活 动经过精心组织，以准确获得最好的效果。
记录全部访谈内容 ④ 安排补充会议 访谈之后 ⑤ 根据标准模版撰写软件需求规格说明（SRS），
打客户需求草稿 ⑥ 通过电子邮件征求客户意见
对于不同类型的应用，用例方法是一种获取和 表达需求的有效方法。
某些需求需要通过数据流图或状态图与用户沟 通。
5.1.2 描述客户需求
需求可以看成是应用与应用的外部代理（如用户） 之间的交互。可利用用例作为表达工具。
流通图书（Book）是指某种馆藏图书（Title）的 某一流通中的复本。例如“数学分析教程第二册” 的 5 本馆藏复本中的第 3 本。
识别用例： a) BorrowBook：借阅流通图书 b) ReturnBook：返还流通图书 c) RecerveTitle：预约某种馆藏图书 d) CancelReservation：取消预约 e) MaintainBorrowerInfo：维护借阅者信息，包 括创建、修改、取消借阅者账户 f) MaintainTitleInfo：维护馆藏图书信息，包
准备和访谈客户的过程如下：
访谈之前 ① 列出访谈的“客户”对象，并划分客户优先级
✓ 最有可能决定项目成败的人 ② 安排访谈日程，设定开始和结束时间
✓ 系统开发人员至少有两人参加访谈 ✓ 准备录音设备 访谈中 ③ 注意倾听 不要处于被动状态：启发和鼓励 ✓ 理解客户的需要并探索要求 ✓ 采用用例？或数据流图？状态图？
6) 标识非功能需求 包括系统性能上的约束、文 档、使用资源、安全性和质量等需求。
需求获取期间，开发人员需要访问一些不同的信 息资源： ✓ 客户提供的与应用领域相关的文档和手册。 ✓ 将被目标系统替代的遗留系统的技术文档。 ✓ 最终用户和客户本人。
以“图书管理系统”为例，首先标识参与者： a) Librarian 图书管理员：创建、修改、删除借 阅者信息；添加、编辑、删除馆藏图书信息； 添加、编辑、删除流通图书信息。 b) Borrower 借阅者：借阅、预约、归还流通图书， 以及取消图书预约。
即使所有利益相关者的需求一致，也可能由于 实现代价高昂，需求不能得到完全满足。
3) 了解客户的需求
一般客户希望得到一个产品，他们需要系统开 发人员帮助，明确自己的需要。
例如，有一个客户愿望框架：“Encounter是一 个角色扮演游戏，它能模拟被扮演人物的全部 或部分活动，应对人们具有相当吸引力。”
高度受限的
军事战略决策支持系统 Encounter视频游戏 公司财务系统 制造控制系统 公司财务系统增强版 航班控制系统 导弹制导系统
相对低的
从人群获取需求的大概百分比
相对高的
所谓限制，是指受客观物理规律的限制。如导弹 制导系统更多地受物理运动定律的限制，而非人 的决策。视频游戏的大部分需求依赖人，因为它 是一个相像出来的产品。
请用户评审
3. 用标准文档格式撰写客户需求
4. 核查用户需求 用户批准后
5. 构建详细需求（分析建模）
5.1.1 与用户交互
1) 需求的来源 不同类型应用能从人员处获取需求的比例:
不受限制的
应 用 的 类 型
应用受到的限制越少，能从人们那里获得的需求 比例越大。
2) 识别利益相关者（stakeholder）
对项目承担风险和享有利益的人即为利益相关者。 他们是应用的“客户”。如公司高层、项目经理、 最终用户、系统开发人员等。
不同利益相关者之间的利益冲突会导致需求不 一致。如果需求冲突不能调和，项目就会陷入 困境，最后往往会被取消。
用例描述了系统外的参与者（Actor）与应用之 间的交互情况。主要注重用户对系统的看法。
描述客户需求的过程如下：
1) 标识参与者 标识目标系统将支持的不同类型 的用户，可以是人、事件或其他系统。
2) 标识场景 用场景描述目标系统典型功能的活 动细节，并与用户沟通，加深开发人员对应用 领域的理解。
括添加、修改、删除馆藏图书信息
g) MaintainBookInfo：维护流通图书信息，包括 添加、修改、删除流通图书信息
一旦系统分析人员对该领域有了充分了解，就可 以建立一个业务模型，描述用户的业务过程，确 定用户的初始需求。然后通过迭代，更深入了解 应用领域，回过头来推敲业务模型。导出用户可理解的系统规格说 明。
开发用户需求的典型过程
1. 识别用户需求
没有专业的系统分析人员，用户很难了解到需要 开发什么相关信息和功能；另一方面，没有与用 户的交流，系统分析人员也很难弄清客户真正需 要什么。
发现用户需求的过程称为需求获取。一旦提出了 最初的需求，进一步推敲、细化和扩充的过程称 为分析。
需求获取的第一步是理解应用领域，即目标软件 的应用环境。如银行、电信公司、书店等。
3) 标识用例 当双方确定了一组场景后，开发人 员从该场景抽象出一组用例，描述所有可能的 情况。用力表达了系统的范围。
4) 求精用例 细化每一个用例。引入带有出错处 理或带有异常处理的用例，描述系统的行为， 保证需求的描述是完全的。
5) 标识用例之间的关系 描述用例之间的依赖关 系，提取相同功能，建立用例模型。
软件工程
第五章 面向对象分析与设计
5.1 需求获取 5.2 面向对象分析 5.3 面向对象设计 5.4 系统设计 5.5 对象设计
整体 概述
一 请在这里输入您的主要叙述内容
二
请在这里输入您的主要 叙述内容
三 请在这里输入您的主要叙述内容
2
5.1 需求获取
需求获取的目标是确定用户“需要”什么样的软 件产品，就是说，新的软件必须能够做什么。
完整的客户要求应当记录在需求文档的“概述” 部分。但需求中还有一些问题需要由系统分析 人员与客户商量，以明确这些需求。
例如游戏是否只允许玩家扮演一个角色还是可 以同时控制多个人物？当两个人相遇时会发生 什么事情？游戏是否可以联网对战等。
4) 访谈和文档记录
大部分需求获取是人与人沟通的活动，这些活 动经过精心组织，以准确获得最好的效果。
记录全部访谈内容 ④ 安排补充会议 访谈之后 ⑤ 根据标准模版撰写软件需求规格说明（SRS），
打客户需求草稿 ⑥ 通过电子邮件征求客户意见
对于不同类型的应用，用例方法是一种获取和 表达需求的有效方法。
某些需求需要通过数据流图或状态图与用户沟 通。
5.1.2 描述客户需求
需求可以看成是应用与应用的外部代理（如用户） 之间的交互。可利用用例作为表达工具。
流通图书（Book）是指某种馆藏图书（Title）的 某一流通中的复本。例如“数学分析教程第二册” 的 5 本馆藏复本中的第 3 本。
识别用例： a) BorrowBook：借阅流通图书 b) ReturnBook：返还流通图书 c) RecerveTitle：预约某种馆藏图书 d) CancelReservation：取消预约 e) MaintainBorrowerInfo：维护借阅者信息，包 括创建、修改、取消借阅者账户 f) MaintainTitleInfo：维护馆藏图书信息，包
准备和访谈客户的过程如下：
访谈之前 ① 列出访谈的“客户”对象，并划分客户优先级
✓ 最有可能决定项目成败的人 ② 安排访谈日程，设定开始和结束时间
✓ 系统开发人员至少有两人参加访谈 ✓ 准备录音设备 访谈中 ③ 注意倾听 不要处于被动状态：启发和鼓励 ✓ 理解客户的需要并探索要求 ✓ 采用用例？或数据流图？状态图？
6) 标识非功能需求 包括系统性能上的约束、文 档、使用资源、安全性和质量等需求。
需求获取期间，开发人员需要访问一些不同的信 息资源： ✓ 客户提供的与应用领域相关的文档和手册。 ✓ 将被目标系统替代的遗留系统的技术文档。 ✓ 最终用户和客户本人。
以“图书管理系统”为例，首先标识参与者： a) Librarian 图书管理员：创建、修改、删除借 阅者信息；添加、编辑、删除馆藏图书信息； 添加、编辑、删除流通图书信息。 b) Borrower 借阅者：借阅、预约、归还流通图书， 以及取消图书预约。
即使所有利益相关者的需求一致，也可能由于 实现代价高昂，需求不能得到完全满足。
3) 了解客户的需求
一般客户希望得到一个产品，他们需要系统开 发人员帮助，明确自己的需要。
例如，有一个客户愿望框架：“Encounter是一 个角色扮演游戏，它能模拟被扮演人物的全部 或部分活动，应对人们具有相当吸引力。”
高度受限的
军事战略决策支持系统 Encounter视频游戏 公司财务系统 制造控制系统 公司财务系统增强版 航班控制系统 导弹制导系统
相对低的
从人群获取需求的大概百分比
相对高的
所谓限制，是指受客观物理规律的限制。如导弹 制导系统更多地受物理运动定律的限制，而非人 的决策。视频游戏的大部分需求依赖人，因为它 是一个相像出来的产品。