软件工程：实践者的研究方法(第七版)_全部讲节讲义.pdfVIP

软件工程 第5章 需求建模：场景、信息与类分析 主要内容 需求分析 基于场景建模 补充用例的UML模型 数据建模概念 基于类的建模 小结 分析模型 文字记录是极好的交流工具，但并不必然 是表达计算机软件需求的最好方式。分析 建模使用文字和图表的综合形式，以相对 容易理解的方式描绘需求的数据、功能和 行为，更重要的是，可以更直接地评审它 们的正确性、完整性和一致性。 软件工程师使用从客户那里提取的需求构 建模型。 分析模型 可以使用很多不同格式的图表为信息、功 能和行为需求建模。基于场景的建模从用 户的角度表现系统；面向流的建模在说明 数据对象如何通过处理函数进行转换方面 提供了指示；基于类的建模定义了对象、 属性和关系；行为建模描述了系统状态、 类和事件在这些类上的影响。一旦创建了 模型的雏形，就将不断改进，并分析评估 其清晰性、完整性和一致性。最终的分析 模型将由所有的共利益者确认。 分析模型  必须评审分析建模工作产品的正确性、 完整性和一致性，必须反映所有共利益者 的要求并建立一个可以从中导出设计的基 础。 分析模型 在技术层面上，软件工程开始于一系列的 建模工作，最终生成待开发软件的需求规 格说明和全面的设计表示。需求模型实际 上是一组模型，是系统的第一个技术表示。 分析阶段的目标[DEM79] 分析的结果必须是高度可维护的，尤其是 要将此结果应用于目标文档。 必须使用一种有效的分割方法解决规模问 题。 尽可能使用图形符号。 考虑问题必须区分逻辑的和物理的。 需求分析 需求分析产生软件操作特征的规格说明， 指明软件和其他系统元素的接口，建立软 件必须满足的约束。需求分析让软件工程 师细化在前期需求工程的起始、导出、谈 判任务中建立的基础需求。 需求分析 需求建模动作产生为以下一种或多种模型类型： 场景建模：出自各种系统 “参与者”观点的需 求。 数据模型：描述问题信息域的模型。 面向类的模型：表示面向对象类的模型，其方 式为通过类的协作获得系统需求。 面向流程的模型：表示系统的功能元素并且描 述当功能元素在系统中运行时怎样进行数据变换 的模型。 行为模型：描述如何将软件行为看做是外部 “事件”后续的模型。 需求分析 在整个需求建模过程中，软件工程师的主 要关注点集中在 “做什么”而不是 “怎么 做”方面。包括：在特定环境下发生哪些 用户交互？系统处理什么对象？系统必须 执行什么功能？系统显示什么行为？定义 什么接口？有什么约束？ 总体目标和原理 需求模型必须实现三个主要目标：  描述客户需要什么；  为软件设计奠定基础；  定义在软件完成后可以被确认的一组需求。 分析模型在系统级描述和软件设计的差距之间 建立桥梁。 重要的是要注意到在系统描述中给出分析模型 的某些元素，并且需求工程的工作实际上是作为 系统工程的一部分开始的。此外，分析模型的所 有元素都可以直接跟踪到设计模型。通常难以区 分这两个重要的建模活动之间的设计和分析工作， 有些设计总是作为分析的一部分进行，而有些分 析将在设计中进行。 分析模型在系统描述和设计模型之间建立桥梁 图5-1分析模型在系统描述和设计模型之间建立桥梁 分析的经验原则[ARL02] 模型应关注在问题域或业务域内可见的需求， 抽象的级别应该相对高一些。 分析模型的每个元素都应能增加对软件需求的 整体理解，并提供对信息域、功能和系统行为的 深入理解。 关于基础结构和其他非功能的模型应推延到设 计阶段再考虑。 最小化整个系统内的关联。 确认分析模型为所有共利益者都带来价值。 尽可能保持模型简洁。 域分析 分析模型通常在特定业务领域内的很多应 用中重复发生。如果用一种方式对这些模 式加以定义和分类，让软件工程师或分析 师识别并复用这些模式，将促进分析模型 的创建。更重要的是，应用可复用的设计 模式和可执行的软件构件的可能性将显著 增加。 域分析 软件域分析是识别、分析和详细说明来自 某个特定应用领域的公共需求，特别是那 些在该应用领域内被多个项目重复使用 的……“面向对象的域分析”是在某个特 定应用领域内，根据通用的对象、类、部 件和框架、识别、分析和详细说明公共的、 可复用的能力。 域分析的目标很简单，就是：查找或创建 那