软件设计ZhouSu第3章需求模型：场景、信息与类分析详解.ppt

软件体系结构与设计 第3章 需求建模：场景、信息与类分析 第3章 需求建模：场景、信息与类分析 需求分析 基于场景建模 补充用例的UML模型 数据建模概念 基于类的建模 第3章 需求建模：场景、信息与类分析 在技术层面上，软件工程开始于一系列的建模工作，最终生成待开发软件的需求规格说明和设计表示。需求模型实际上是一组模型，是系统的第一个技术表示。而需求建模的目标是创建各种表现形式，用其描述什么是客户需求，建立生成软件设计的基础，一旦软件建立就能定义一组可被确认的需求。需求模型在系统级表示层和软件设计之间构造了桥梁。系统表示层描述整个系统和业务功能，软件设计描述软件应用的架构、用户接口和组件级的结构。 3.1 需求分析 需求分析产生所开发软件的规格说明，指明软件和其他系统元素的接口，规定软件必须满足的约束，并且让软件工程师（有时也称软件分析师或软件架构师）细化在前期需求工程的起始、导出、谈判任务中建立的基础需求。 3.1 需求分析 需求建模活动产生以下一种或多种模型类型： 场景模型：出自各种系统“参与者”观点的需求。 数据模型：描述问题信息域的模型。 面向类的模型：表示面向对象类（属性和操作）的模型，其方式为通过类的协作获得系统需求。 面向流程的模型：表示系统的功能元素并且描述当功能元素在系统中运行时怎样进行数据变换的模型。 行为模型：描述如何将软件行为看做是外部“事件”后续的模型。 3.1 需求分析 其中，基于场景的建模技术在软件工程界迅速发展；数据建模是较为特殊的技术，适用于当一个应用问题必须生成或处理一个复杂的信息空间时；面向类建模表示面向对象类和允许的系统功能间的有效协作。 这些模型为软件设计者提供信息，这些信息可以转化为结构、接口和构件级的设计。最终，在软件开发完成后，需求模型（和需求规格说明）就为开发人员和客户提供了评估软件质量的手段。 3.1.1 总体目标和原理 在需求建模过程中，软件工程师主要关注“做什么”而不是“怎么做”。包括：在特定环境下发生哪些用户交互？系统处理什么对象？系统必须执行什么功能？系统展示什么行为？定义什么接口？有什么约束。？ 由于在初期就要得到完整的需求规格说明是不可能的，因此分析师将为已经知道的内容建模，并使用该模型作为软件进一步扩展的设计基础。 3.1.1 总体目标和原理 需求模型必须实现三个主要目标： ① 描述客户需要什么； ② 为软件设计奠定基础； ③ 定义在软件完成后可以被确认的一组需求。 分析模型在系统级描述和软件设计之间建立了桥梁。这里，系统级描述给出了在软件、硬件、数据、人员和其他系统元素共同作用下的整个系统或商业功能，而软件设计给出了软件的应用程序结构、用户接口以及构件级的结构，其关系如图3-1所示。 3.1.1 总体目标和原理 重要的是要注意需求模型的所有元素都可以直接跟踪到设计模型。通常很难清楚地区分这两个重要的建模活动之间的设计和分析工作，有些设计会作为分析的一部分进行，而有些分析将在设计中进行。 3.1.2 分析的经验原则 在创建分析模型时应该遵循的一些有价值的经验原则是： 模型应关注在问题域或业务域内可见的需求，抽象的级别应该相对高一些。“不要陷入细节”，即不要试图解释系统将如何工作。 需求模型的每个元素都应能增加对软件需求的整体理解，并提供对信息域、功能和系统行为的深入理解。 关于基础结构和其他非功能的模型应推迟到设计阶段再考虑。例如，可能需要一个数据库，但是只有在已经完成问题域分析之后，才考虑实现数据库所必需的类、访问数据库所需的功能，以及使用时所表现出的行为。 3.1.2 分析的经验原则 最小化整个系统内的关联。表现类和功能之间的联系非常重要，但是，如果“互联”的层次非常高，应该想办法减少互联。 确认需求模型为所有利益相关者都带来价值。对模型来说，每个客户都有自己的使用目的。例如，利益相关的业务人员将使用模型确认需求，设计人员将使用模型作为设计的基础，质量管理人员将使用模型帮助规划验收测试。 尽可能保持模型简洁。如果没有提供新的信息，不要添加附加图表；如果一个简单列表就够用，就不要使用复杂的表示方法。 3.1.3 域分析 分析模式通常在特定业务领域内的很多应用系统中重复发生。如果用一种方式对这些模式加以定义和分类，让软件工程师或分析师识别并复用这些模式，将促进分析模型的创建。更重要的是，应用可复用的设计模式和可执行的软件构件的可能性将显著增加。这将有可能使产品投放市场的时间提前，并减少开发费用。 3.1.3 域分析 对域分析的描述可以是：“软件域分析是识别、分析和详细说明某个特定应用领域的公共需求，特别是那些在该应用领域内被多个项目重复使用的需求……面向对象的域分析是在某个特定应用领域内，根据通用的对象、类、部件和框架，识