软件工程:实践者的研究方法第七版)_全部章节讲义

上传人:E**** 文档编号:104737379 上传时间:2019-10-10 格式:PDF 页数:83 大小:1.97MB
返回 下载 相关 举报
软件工程:实践者的研究方法第七版)_全部章节讲义_第1页
第1页 / 共83页
软件工程:实践者的研究方法第七版)_全部章节讲义_第2页
第2页 / 共83页
软件工程:实践者的研究方法第七版)_全部章节讲义_第3页
第3页 / 共83页
软件工程:实践者的研究方法第七版)_全部章节讲义_第4页
第4页 / 共83页
软件工程:实践者的研究方法第七版)_全部章节讲义_第5页
第5页 / 共83页
点击查看更多>>
资源描述

《软件工程:实践者的研究方法第七版)_全部章节讲义》由会员分享,可在线阅读,更多相关《软件工程:实践者的研究方法第七版)_全部章节讲义(83页珍藏版)》请在金锄头文库上搜索。

1、软件工程 第5章 需求建模:场景、信息与类分析 主要内容 需求分析需求分析 基于场景建模基于场景建模 补充用例的补充用例的UML模型模型 数据建模概念数据建模概念 基于类的建模基于类的建模 小结小结 分析模型 文字记录是极好的交流工具,但并不必然文字记录是极好的交流工具,但并不必然 是表达计算机软件需求的最好方式。是表达计算机软件需求的最好方式。分析分析 建模使用文字和图表的综合形式建模使用文字和图表的综合形式,以相对,以相对 容易理解的方式描绘需求的数据、功能和容易理解的方式描绘需求的数据、功能和 行为,更重要的是,可以更直接地评审它行为,更重要的是,可以更直接地评审它 们的正确性、完整性和

2、一致性。们的正确性、完整性和一致性。 软件工程师使用从软件工程师使用从客户那里提取的需求客户那里提取的需求构构 建模型。建模型。 分析模型 可以使用很多不同格式的图表为信息、功可以使用很多不同格式的图表为信息、功 能和行为需求建模。能和行为需求建模。基于场景的建模基于场景的建模从用从用 户的角度表现系统;户的角度表现系统;面向流的建模面向流的建模在说明在说明 数据对象如何通过处理函数进行转换方面数据对象如何通过处理函数进行转换方面 提供了指示;提供了指示;基于类的建模基于类的建模定义了对象、定义了对象、 属性和关系;属性和关系;行为建模行为建模描述了系统状态、描述了系统状态、 类和事件在这些类

3、上的影响。一旦创建了类和事件在这些类上的影响。一旦创建了 模型的雏形,就将不断改进,并分析评估模型的雏形,就将不断改进,并分析评估 其清晰性、完整性和一致性。最终的分析其清晰性、完整性和一致性。最终的分析 模型将由模型将由所有的共利益者所有的共利益者确认。确认。 分析模型 必须评审分析建模工作产品的正确性、必须评审分析建模工作产品的正确性、 完整性和一致性,必须反映完整性和一致性,必须反映所有共利益者所有共利益者 的要求的要求并建立一个可以从中导出设计的基并建立一个可以从中导出设计的基 础。础。 分析模型 在技术层面上,软件工程开始于一系列的在技术层面上,软件工程开始于一系列的 建模工作,最终

4、生成待开发软件的需求规建模工作,最终生成待开发软件的需求规 格说明和全面的设计表示。格说明和全面的设计表示。需求模型需求模型实际实际 上是一组模型,是系统的第一个技术表示。上是一组模型,是系统的第一个技术表示。 分析阶段的目标DEM79 分析的结果必须是高度可维护的,尤其是分析的结果必须是高度可维护的,尤其是 要将此结果应用于目标文档。要将此结果应用于目标文档。 必须使用一种有效的分割方法解决规模问必须使用一种有效的分割方法解决规模问 题。题。 尽可能使用图形符号。尽可能使用图形符号。 考虑问题必须考虑问题必须区分逻辑的和物理的区分逻辑的和物理的。 需求分析 需求分析产生软件操作特征的规格说明

5、,需求分析产生软件操作特征的规格说明, 指明软件和其他系统元素的接口,建立软指明软件和其他系统元素的接口,建立软 件必须满足的约束。需求分析让软件工程件必须满足的约束。需求分析让软件工程 师细化在前期需求工程的起始、导出、谈师细化在前期需求工程的起始、导出、谈 判任务中建立的基础需求。判任务中建立的基础需求。 需求分析 需求建模动作产生为以下一种或多种模型类型:需求建模动作产生为以下一种或多种模型类型: 场景建模:出自各种系统场景建模:出自各种系统“参与者参与者”观点的需观点的需 求。求。 数据模型数据模型:描述问题信息域的模型。:描述问题信息域的模型。 面向类的模型面向类的模型:表示面向对象

6、类的模型,其方:表示面向对象类的模型,其方 式为通过类的协作获得系统需求。式为通过类的协作获得系统需求。 面向流程的模型面向流程的模型:表示系统的功能元素并且描:表示系统的功能元素并且描 述当功能元素在系统中运行时怎样进行数据变换述当功能元素在系统中运行时怎样进行数据变换 的模型。的模型。 行为模型:行为模型:描述如何将软件行为看做是外部描述如何将软件行为看做是外部 “事件事件”后续的模型。后续的模型。 需求分析 在整个需求建模过程中,软件工程师的主在整个需求建模过程中,软件工程师的主 要关注点集中在要关注点集中在“做什么做什么”而而不是不是“怎么怎么 做做”方面。包括:在特定环境下发生哪些方

7、面。包括:在特定环境下发生哪些 用户交互?系统处理什么对象?系统必须用户交互?系统处理什么对象?系统必须 执行什么功能?系统显示什么行为?定义执行什么功能?系统显示什么行为?定义 什么接口?有什么约束?什么接口?有什么约束? 总体目标和原理 需求模型必须实现三个主要目标:需求模型必须实现三个主要目标: 描述客户需要什么;描述客户需要什么; 为软件设计奠定基础;为软件设计奠定基础; 定义在软件完成后可以被确认的一组需求。定义在软件完成后可以被确认的一组需求。 分析模型在系统级描述和软件设计的差距之间分析模型在系统级描述和软件设计的差距之间 建立桥梁。建立桥梁。 重要的是要注意到在系统描述中给出分

8、析模型重要的是要注意到在系统描述中给出分析模型 的某些元素,并且需求工程的工作实际上是作为的某些元素,并且需求工程的工作实际上是作为 系统工程的一部分开始的。此外,分析模型的所系统工程的一部分开始的。此外,分析模型的所 有元素都可以直接跟踪到设计模型。通常难以区有元素都可以直接跟踪到设计模型。通常难以区 分这两个重要的建模活动之间的设计和分析工作,分这两个重要的建模活动之间的设计和分析工作, 有些设计总是作为分析的一部分进行,而有些分有些设计总是作为分析的一部分进行,而有些分 析将在设计中进行。析将在设计中进行。 分析模型在系统描述和设计模型之间建立桥梁 图5-1分析模型在系统描述和设计模型之

9、间建立桥梁 分析的经验原则ARL02 模型应关注在问题域或业务域内模型应关注在问题域或业务域内可见的需求可见的需求, 抽象的级别应该相对高一些。抽象的级别应该相对高一些。 分析模型的每个元素都应能增加对软件需求的分析模型的每个元素都应能增加对软件需求的 整体理解,并提供对整体理解,并提供对信息域、功能和系统行为信息域、功能和系统行为的的 深入理解。深入理解。 关于基础结构和其他非功能的模型应推延到设关于基础结构和其他非功能的模型应推延到设 计阶段再考虑。计阶段再考虑。 最小化整个系统内的关联。最小化整个系统内的关联。 确认分析模型为所有共利益者都带来价值。确认分析模型为所有共利益者都带来价值。

10、 尽可能保持模型简洁。尽可能保持模型简洁。 域分析 分析模型通常在特定业务领域内的很多应分析模型通常在特定业务领域内的很多应 用中重复发生。如果用一种方式对这些模用中重复发生。如果用一种方式对这些模 式加以定义和分类,让软件工程师或分析式加以定义和分类,让软件工程师或分析 师识别并复用这些模式,将促进分析模型师识别并复用这些模式,将促进分析模型 的创建。更重要的是,应用可复用的设计的创建。更重要的是,应用可复用的设计 模式和可执行的软件构件的可能性将显著模式和可执行的软件构件的可能性将显著 增加。增加。 域分析 软件域分析是识别、分析和详细说明来自软件域分析是识别、分析和详细说明来自 某个特定

11、应用领域的公共需求某个特定应用领域的公共需求,特别是那,特别是那 些在该应用领域内被多个项目重复使用些在该应用领域内被多个项目重复使用 的的“面向对象的域分析面向对象的域分析”是在某个特是在某个特 定应用领域内,根据通用的对象、类、部定应用领域内,根据通用的对象、类、部 件和框架、识别、分析和详细说明公共的、件和框架、识别、分析和详细说明公共的、 可复用的能力。可复用的能力。 域分析的目标很简单,就是:查找或创建域分析的目标很简单,就是:查找或创建 那些分析类和(或)能够那些分析类和(或)能够广泛应用的、共广泛应用的、共 有的功能和特点有的功能和特点,这样就可以复用。,这样就可以复用。 域分析

12、的输入和输出 课本图5-2 域分析的输入和输 出 需求建模的方法 一种考虑数据和处理的需求建模方法被称一种考虑数据和处理的需求建模方法被称 作作结构化分析结构化分析,其中数据作为独立实体转,其中数据作为独立实体转 换。数据对象建模定义了对象的属性和关换。数据对象建模定义了对象的属性和关 系,操作数据对象的处理建模应表明当数系,操作数据对象的处理建模应表明当数 据对象在系统内流动时处理如何转换数据。据对象在系统内流动时处理如何转换数据。 分析建模的第二种方法称作分析建模的第二种方法称作面向对象的分面向对象的分 析析,这种方法关注于定义类和影响客户需,这种方法关注于定义类和影响客户需 求的类之间的

13、协作方式。求的类之间的协作方式。UML和统一过程和统一过程 主要是面向对象的。主要是面向对象的。 分析建模的方法 软件团队往往软件团队往往选择一种方法并排斥另一种方法选择一种方法并排斥另一种方法 中的所有表示手段。问题不是哪一种方法最好,中的所有表示手段。问题不是哪一种方法最好, 而是怎么而是怎么组合组合这些表示手段才能够为共利益者提这些表示手段才能够为共利益者提 供最好的软件需求模型和过渡到软件设计的最有供最好的软件需求模型和过渡到软件设计的最有 效方法。效方法。 分析模型将生成如课本图分析模型将生成如课本图5-3所示的每个建模所示的每个建模 元素的派生类。然而,不同项目之间,每个元素元素的

14、派生类。然而,不同项目之间,每个元素 的特定内容可能因项目而异。软件团队必须想办的特定内容可能因项目而异。软件团队必须想办 法保持模型的简单性。只有那些法保持模型的简单性。只有那些为模型增加价值为模型增加价值 的建模元素才能使用的建模元素才能使用。 分析模型的元素 图5-3 分析模型的元素 基于场景建模 如果软件工程师了解最终用户(和其他参如果软件工程师了解最终用户(和其他参 与者)希望如何与系统交互,软件团队将与者)希望如何与系统交互,软件团队将 能够更好地、更准确地刻画系统特征,完能够更好地、更准确地刻画系统特征,完 成更有针对性的分析和设计模型。使用成更有针对性的分析和设计模型。使用 U

15、ML分析建模,将从开发用例、活动图和分析建模,将从开发用例、活动图和 泳道图形式的场景开始。泳道图形式的场景开始。 编写用例 用例捕获信息的产生者、使用者和系统本用例捕获信息的产生者、使用者和系统本 身之间发生的交互。身之间发生的交互。 用例从某个特定参与者的角度用简单易懂用例从某个特定参与者的角度用简单易懂 的语言说明一个特定的使用场景。但是我的语言说明一个特定的使用场景。但是我 们应该知道:们应该知道:(1)编写什么?编写什么?(2)写多少?写多少? (3)编写说明应该多详细?编写说明应该多详细?(4)如何组织说如何组织说 明?明? 编写用例 两个首要的需求工程工作两个首要的需求工程工作起

16、始和导起始和导 出出提供了开始编写用例所需要的信息。提供了开始编写用例所需要的信息。 运用需求收集会议、运用需求收集会议、QFD和其他需求工程和其他需求工程 机制确定共利益者,定义问题的范围,说机制确定共利益者,定义问题的范围,说 明整体的操作目标,概述所有已知的功能明整体的操作目标,概述所有已知的功能 需求,描述系统将处理的信息(对象)。需求,描述系统将处理的信息(对象)。 要开始开发用例,应列出特定参与者执行要开始开发用例,应列出特定参与者执行 的功能或活动。这些可以从所需系统功能的功能或活动。这些可以从所需系统功能 的列表中获得,或通过与客户或最终用户的列表中获得,或通过与客户或最终用户 交流获得,或通过评估活动图获得。交流获得,或通过评估活动图获得。 SafeHome实例12 SafeHome住宅监视功能(子系统)确定住宅监视功能(子系统)确定 了如下由参与者房主执行的功能:了如下由参与者房主执行的功能: 选择将要查看的摄像机。选择

展开阅读全文
相关资源
正为您匹配相似的精品文档
相关搜索

最新文档


当前位置:首页 > 高等教育 > 大学课件

电脑版 |金锄头文库版权所有
经营许可证:蜀ICP备13022795号 | 川公网安备 51140202000112号