SWEBOK软件工程知识体系 - 9.软件工程模型与方法

软件工程模型与方法 (SOFTWARE ENGINEERING MODELS AND METHODS)

软件工程模型和方法将结构强加给软件工程，目的是使该活动系统化、可重复，并最终更加面向成功。使用模型提供了一种解决问题的方法、一种表示法以及模型构建和分析的过程。方法提供了一种方法来系统地说明、设计、构造、测试和验证最终项目软件和相关工作产品。

软件工程模型和方法在范围上有很大的不同，从处理单个软件生命周期阶段到覆盖整个软件生命周期。这一知识领域（KA）的重点是包含多个软件生命周期阶段的软件工程模型和方法，因为特定于单个生命周期阶段的方法被其他KA所涵盖。

软件工程模型和方法的主题分解
关于软件工程模型和方法的这一章分为四个主要主题领域：

• 建模：讨论建模的一般实践，并介绍建模原则；模型的属性和表达；建模语法、语义和语用；以及前置条件、后置条件和不变量。
• 模型类型：简要讨论模型和子模型的聚合，并提供软件工程实践中常见的模型类型的一些一般特征。
• 模型分析：介绍建模中使用的一些常见分析技术，以验证完整性、一致性、正确性、可追溯性和交互。
• 软件工程方法：简要概述常用的软件工程方法。讨论通过启发式方法、形式化方法、原型和敏捷方法的总结来指导读者。

软件工程模型和方法的主题细分如图9.1所示。

1.建模

软件建模正成为一种普遍的技术，帮助软件工程师理解、设计软件，并将软件的各个方面传达给适当的利益相关者。涉众是那些对软件有明确或暗示利益的人或当事人（例如，用户、买方、供应商、架构师、认证机构、评估者、开发人员、软件工程师，也许还有其他人）。
虽然在文献和实践中有许多建模语言、符号、技术和工具，但是有一些统一的通用概念以某种形式应用于它们。以下各节提供了这些一般概念的背景知识。

1.1. 建模原则

建模为软件工程师提供了一种有组织和系统的方法，用于表示所研究软件的重要方面，促进有关软件或其元素的决策，并将这些重要决策传达给利益相关者社区中的其他人。指导此类建模活动的一般原则有三条：

• 建模要素：好的模型通常不能代表软件在所有可能条件下的所有方面或特性。建模通常只涉及开发那些需要特定答案的软件方面或功能，抽象掉任何不重要的信息。这种方法保持了模型的可管理性和实用性。
• 提供透视图：建模使用一组定义的规则来表示每个视图中的模型，从而提供所研究软件的视图。这种透视驱动的方法为模型提供了维度（例如，结构视图、行为视图、时间视图、组织视图和其他相关视图）。将信息组织到视图中，使用适当的符号、词汇表、方法和工具将软件建模工作集中在与视图相关的特定关注点上。
• 实现有效的通信：建模使用软件的应用领域词汇表、建模语言和语义表达（换句话说，上下文中的含义）。当严格而系统地使用时，这种建模会产生一种报告方法，这种方法有助于将软件信息有效地传达给项目涉众。

模型是软件组件的抽象或简化。使用抽象的一个结果是没有一个抽象完全描述了软件组件。相反，软件的模型被表示为抽象的集合，当这些抽象结合在一起时，只描述选定的方面、视角或视图，而这些方面、视角或视图仅仅是做出明智的决策和响应创建模型的原因所需要的。这种简化导致了一组关于放置模型的上下文的假设，这些假设也应该被捕获到模型中。然后，在重用模型时，可以首先验证这些假设，以确定重用模型在其新用途和上下文中的相关性。

1.2. 模型的性质与表达

模型属性是特定模型的那些显著特征，用于在所选的建模符号和所用工具中描述其完整性、一致性和正确性。模型的属性包括：

• 完整性：所有需求在模型中得到实施和验证的程度。
• 一致性：模型不包含冲突的需求、断言、约束、功能或组件描述的程度。
• 正确性：模型满足其要求和设计规范且无缺陷的程度。

模型被构造来表示真实世界的对象及其行为，以回答有关软件如何运行的特定问题。通过探索、模拟或审查来询问模型可能会暴露模型和模型所指软件中的不确定性区域。这些关于需求、设计和/或实现的不确定性或未回答的问题可以得到适当的处理。

模型的主要表达式元素是实体。实体可以表示具体工件（例如，处理器、传感器或机器人）或抽象工件（例如，软件模块或通信协议）。模型实体使用关系（换句话说，目标实体上的行或文本操作符）连接到其他实体。模型实体的表达可以使用文本或图形建模语言来完成；这两种建模语言类型都通过特定的语言构造来连接模型实体。实体的意义可以通过其形状、文本属性或两者来表示。一般来说，文本信息遵循特定于语言的句法结构。与使用这些实体和关系对上下文、结构或行为进行建模相关的精确含义取决于所使用的建模语言、应用于建模工作的设计严谨性、正在构建的特定视图以及特定符号元素可能附加到的实体。可能需要模型的多个视图来捕获所需的软件语义。

当使用自动化支持的模型时，可以检查模型的完整性和一致性。这些检查的有用性在很大程度上取决于应用于建模工作的语义和语法的严格程度以及明确的工具支持。正确性通常通过模拟和/或审查进行检查。

1.3. 句法、语义和语用学

模型可能具有惊人的欺骗性。一个模型是一个缺少信息的抽象，这一事实可能会导致一个人从一个单一的模型中完全理解软件。一个完整的模型（“完整”与建模工作有关）可以是多个子模型和任何特殊功能模型的联合。与子模型集合中的单个模型相关的检查和决策可能存在问题。

理解建模构造的精确含义也很困难。建模语言由语法和语义规则定义。对于文本语言，语法是使用定义有效语言结构的符号语法来定义的（例如，Backus Naur Form（BNF））。对于图形语言，语法是使用称为元模型的图形模型定义的。与BNF一样，元模型定义了图形建模语言的有效语法结构；元模型定义了如何组合这些结构来生成有效的模型。

建模语言的语义指定了附加到模型中捕获的实体和关系的含义。例如，一个简单的由一条线连接的两个盒子的图表可以有多种解释。知道放置和连接这些框的图是对象图或活动图有助于解释这个模型。

作为一个实际问题，通常对特定软件模型的语义有很好的理解，这是由于所选的建模语言、如何使用该建模语言来表示该模型中的实体和关系、建模者的经验基础，以及建模所处的环境。即使存在抽象的不完整信息，意义也通过模型来传达；语用学解释了意义如何体现在模型及其上下文中，并有效地传达给其他软件工程师。

然而，仍有一些实例需要注意建模和语义。例如，必须检查从另一个模型或库导入的任何模型零件在新建模环境中是否存在冲突的语义假设；这可能并不明显。应检查模型是否有记录在案的假设。虽然建模语法可能是相同的，但模型在新环境中的含义可能完全不同，这是一个不同的上下文。另外，考虑到随着软件的成熟和变化，语义上的不一致可能被引入，从而导致错误。随着时间的推移，许多软件工程师在模型部件上工作，再加上工具更新和可能的新需求，模型的某些部分有机会表示与原始作者的意图和初始模型上下文不同的内容。

1.4. 先决条件、后条件和不变量

在建模函数或方法时，软件工程师通常从一组关于函数或方法执行之前、期间和之后的软件状态的假设开始。这些假设对于函数或方法的正确操作是必不可少的，并且作为一组先决条件、后决条件和不变量进行分组讨论。

• 前提条件：在执行函数或方法之前必须满足的一组条件。如果这些前提条件在函数或方法执行之前不成立，则函数或方法可能产生错误的结果。
• 后置条件：在函数或方法成功执行后保证为真的一组条件。通常，后置条件表示软件的状态如何更改，传递给函数或方法的参数如何更改，数据值如何更改，或者返回值如何受到影响。
• 不变量：操作环境中的一组条件，在函数或方法执行前后保持不变（换句话说，不变）。这些不变量对于软件和函数或方法的正确操作是相关和必要的。
  
  

2.模型类型

典型的模型由子模型的聚合组成。每个子模型都是一个局部描述，是为特定目的而创建的；它可以由一个或多个图组成。子模型的集合可以使用多种建模语言或单个建模语言。统一建模语言（UML）可以识别大量的建模图。这些图的使用，以及建模语言构造，带来了三种广泛使用的模型类型：信息模型、行为模型和结构模型（见第1.1节）。

2.1. 信息建模

信息模型集中于数据和信息。信息模型是一种抽象表示，它标识和定义了数据实体上的一组概念、属性、关系和约束。从问题的角度来看，语义或概念信息模型通常用于为被建模的软件提供某种形式主义和上下文，而不关心此模型如何实际映射到软件的实现。语义或概念信息模型是一种抽象，因此，仅包括概念化信息的真实世界视图所需的概念、属性、关系和约束。语义或概念信息模型的后续转换导致在软件中实现的逻辑和物理数据模型的细化。

2.2. 行为建模

行为模型识别并定义被建模软件的功能。行为模型通常有三种基本形式：状态机、控制流模型和数据流模型。状态机提供了一个软件模型，作为已定义状态、事件和转换的集合。软件通过在建模环境中发生的有保护或无保护触发事件从一种状态转换到下一种状态。控制流模型描述了一系列事件如何导致流程被激活或停用。数据流行为被典型化为一系列步骤，在这些步骤中，数据通过进程向数据存储或数据接收器移动。

2.3. 结构建模

结构模型从软件的各个组成部分说明了软件的物理或逻辑组成。结构建模在被实现或建模的软件和它要运行的环境之间建立了定义的边界。结构建模中使用的一些常见结构构造包括实体的组合、分解、泛化和专门化；实体之间相关关系和基数的识别；以及过程或功能接口的定义。UML为结构建模提供的结构图包括类、组件、对象、部署和打包图。

3.模型分析

模型的开发为软件工程师提供了一个研究、推理和理解与软件相关的结构、功能、操作使用和装配注意事项的机会。需要对构建的模型进行分析，以确保这些模型是完整的、一致的和正确的，足以满足利益相关者的预期目的。

接下来的章节简要描述了软件模型通常使用的分析技术，以确保软件工程师和其他相关的利益相关者从模型的开发和使用中获得适当的价值。

3.1. 完整性分析

为了使软件完全满足涉众的需求，从需求获取过程到代码实现，完整性是至关重要的。完整性是指所有规定的要求都得到实施和验证的程度。模型的完整性可以通过使用结构分析和状态空间可达性分析等技术的建模工具进行检查（这些技术可以确保状态模型中的所有路径都由一组正确的输入到达）；还可以使用检查或其他评审技术手动检查模型的完整性（参见软件质量KA）。这些分析工具产生的错误和警告以及通过检查或审查发现的错误和警告表明可能需要采取纠正措施，以确保模型的完整性。

3.2. 一致性分析

一致性是指模型不包含冲突的需求、断言、约束、函数或组件描述的程度。通常，一致性检查是通过使用自动分析功能的建模工具来完成的；还可以使用检查或其他评审技术手动检查模型的一致性（参见软件质量KA）。与完整性一样，这些分析工具产生的错误和警告以及通过检查或评审发现的错误和警告表明需要采取纠正措施。

3.3. 正确性分析

正确性是一个模型满足其软件需求和软件设计规范、没有缺陷并最终满足涉众需求的程度。正确性分析包括验证模型的语法正确性（即正确使用建模语言语法和结构）和验证模型的语义正确性（即使用建模语言结构正确表示被建模对象的含义）。要分析一个模型的语法和语义正确性，可以自动分析它（例如，使用建模工具检查模型语法的正确性）或手动（使用检查或其他评审技术）-搜索可能的缺陷，然后在软件发布使用之前移除或修复已确认的缺陷。

3.4. 可追溯性

开发软件通常涉及许多工作产品的使用、创建和修改，如计划文档、过程规范、软件需求、图表、设计和伪代码、手写和工具生成的代码、手动和自动测试用例和报告以及文件和数据。这些工作产品可以通过各种依赖关系（例如，使用、实现和测试）进行关联。随着软件的开发、管理、维护或扩展，需要映射和控制这些跟踪关系，以证明软件需求与软件模型（见软件需求KA中的需求跟踪）和许多工作产品的一致性。可追溯性的使用通常改进了软件工作产品和软件过程质量的管理；它还向涉众提供了满足所有需求的保证。一旦软件开发和发布，可追溯性就可以进行变更分析，因为可以很容易地遍历与软件工作产品的关系来评估变更影响。建模工具通常提供一些自动化或手动的方法来指定和管理需求、设计、代码和/或测试实体之间的可追溯性链接，如模型和其他软件工作产品中所示。（有关可追溯性的更多信息，请参阅软件配置管理）。

3.5. 交互分析

交互分析的重点是用于完成软件模型中特定任务或功能的实体之间的通信或控制流关系。此分析检查软件模型不同部分之间交互的动态行为，包括其他软件层（如操作系统、中间件和应用程序）。对于某些软件应用程序来说，检查计算机软件应用程序和用户界面软件之间的交互也可能很重要。一些软件建模环境提供了仿真工具来研究建模软件的动态行为。逐步完成模拟为软件工程师提供了一个分析选项，以检查交互设计并验证软件的不同部分协同工作以提供预期的功能。

4.软件工程方法

软件工程方法为目标计算机开发软件提供了一种有组织、系统的方法。有许多方法可供选择，对于软件工程师来说，为手头的软件开发任务选择一种或多种合适的方法是很重要的；这种选择会对软件项目的成功产生巨大的影响。使用这些软件工程方法，再加上具有适当技能和工具的人员，使软件工程师能够可视化软件的细节，并最终将表示转换为代码和工具的工作集数据。已选定下面讨论软件工程方法。主题领域被组织成启发式方法、形式化方法、原型方法和敏捷方法的讨论。

4.1. 启发法

启发式方法是那些基于经验的软件工程方法，已经在软件行业得到了广泛的应用。本主题区域包含三大讨论类别：结构化分析与设计方法、数据建模方法和面向对象分析与设计方法。

• 结构化分析和设计方法：软件模型主要从功能或行为的角度开发，从软件的高级视图（包括数据和控制元素）开始，然后通过越来越详细的设计逐步分解或细化模型组件。详细的设计最终会收敛到非常具体的软件细节或规范，这些细节或规范必须进行编码（手工、自动生成或两者兼有）、构建、测试和验证。
• 数据建模方法：从所用数据或信息的角度构建数据模型。数据表和关系定义了数据模型。此数据建模方法主要用于定义和分析支持数据库设计或数据存储库的数据需求，这些数据通常存在于业务软件中，其中数据作为业务系统资源或资产进行主动管理。
• 面向对象的分析和设计方法：面向对象模型表示为一组对象，这些对象封装数据和关系，并通过方法与其他对象交互。对象可以是真实世界的项目或虚拟项目。软件模型是用图表来构造软件的选定视图。软件模型的逐步完善导致了详细的设计。然后，详细设计要么通过连续的迭代进行演化，要么（使用某种机制）转换到模型的实现视图中，在该视图中表达最终软件产品发布和部署的代码和打包方法。

4.2. 形式化方法

形式化方法是软件工程方法，用于通过应用严格的基于数学的符号和语言来指定、开发和验证软件。通过使用规范语言，可以系统地、自动地或半自动地检查软件模型的一致性（换句话说，不存在歧义）、完整性和正确性。本主题与软件需求KA中的形式化分析部分相关。

本节讨论规范语言、程序精化和派生、形式验证和逻辑推理。

• 规范语言：规范语言为形式化方法提供了数学基础；规范语言是在软件规范、需求分析过程中使用的形式化、更高级的计算机语言（换句话说，不是经典的第三代语言（3GL）编程语言），和/或设计阶段来描述特定的输入/输出行为。规范语言不是直接可执行的语言；它们通常由符号和语法、用于符号的语义以及一组允许的对象关系组成。
• 程序精化和派生：程序精化是使用一系列转换创建较低级别（或更详细）规范的过程。正是通过连续的转换，软件工程师导出了程序的可执行表示。可以细化规范，添加细节，直到可以用3GL编程语言或所选规范语言的可执行部分来表述模型。通过定义具有精确语义属性的规范，可以对规范进行细化；规范不仅必须列出实体之间的关系，还必须列出这些关系和操作的确切运行时含义。
• 形式验证：模型检查是一种形式验证方法；它通常涉及执行状态空间探索或可达性分析，以证明所表示的软件设计具有或保留某些感兴趣的模型属性。模型检查的一个例子是在所有可能的事件或消息到达的交错情况下验证正确程序行为的分析。形式化验证的使用需要严格指定软件及其操作环境的模型；该模型通常采用有限状态机或其他形式化定义的自动机的形式。
• 逻辑推理：逻辑推理是一种设计软件的方法，包括围绕设计的每个重要块指定先决条件和后决条件，并使用数理逻辑证明这些先决条件和后决条件在所有输入下都必须成立。这为软件工程师提供了一种无需执行软件即可预测软件行为的方法。一些集成开发环境（IDE）包含了将这些证明与设计或代码一起表示的方法。

4.3. 原型制作方法

软件原型是一种通常创建软件应用程序的不完整或最低功能版本的活动，通常用于尝试特定的新功能、征求关于软件需求或用户界面的反馈、进一步探索软件需求、软件设计或实现选项，和/或获得对软件的其他有用见解。软件工程师选择一种原型方法来首先理解软件中最不容易理解的方面或组件；这种方法与其他软件工程方法不同，后者通常首先从最容易理解的部分开始开发。通常，如果没有大量的开发返工或重构，原型产品不会成为最终的软件产品。

本节简要讨论原型设计风格、目标和评估技术。

• 原型设计风格：这涉及到开发原型的各种方法。原型可以开发为一次性代码或纸质产品，作为工作设计的演化，或作为可执行规范。每个样式通常使用不同的原型生命周期过程。选择的风格基于项目需要的结果类型、所需结果的质量和结果的紧迫性。
• 原型目标：原型活动的目标是原型工作所服务的特定产品。原型目标的例子包括需求规范、架构设计元素或组件、算法或人机界面。
• 原型评估技术：软件工程师或其他项目干系人可通过多种方式使用或评估原型，主要由导致原型开发的根本原因驱动。原型可以根据实际实现的软件或目标需求集（例如，需求原型）进行评估或测试；原型还可以作为未来软件开发工作的模型（例如，在用户界面规范中）。

4.4. 敏捷方法

敏捷方法诞生于20世纪90年代，源于需要减少大规模软件开发项目中使用的基于计划的重量级方法所带来的明显的巨大开销。敏捷方法被认为是轻量级方法，因为它们的特点是开发周期短、迭代性强、团队自组织、设计更简单、代码重构、测试驱动开发、频繁的客户参与，以及强调在每个开发周期中创建一个可证明的工作产品。

文献中提供了许多敏捷方法；这里简要讨论的一些更流行的方法包括快速应用程序开发（RAD）、极限编程（XP）、Scrum和特性驱动开发（FDD）。

• RAD：快速软件开发方法主要用于数据密集型业务系统应用程序开发。RAD方法通过软件工程师使用的专用数据库开发工具实现，以快速开发、测试和部署新的或修改的业务应用程序。
• XP：这种方法使用需求的故事或场景，首先开发测试，让客户直接参与团队（通常定义验收测试），使用结对编程，并提供连续的代码重构和集成。故事被分解成任务、优先顺序、估计、开发和测试。软件的每一个增量都通过自动和手动测试进行测试；增量可能会频繁发布，比如每两周左右发布一次。
• Scrum：这种敏捷方法比其他方法更便于项目管理。scrum主管管理项目增量中的活动；每个增量称为sprint，持续时间不超过30天。产品待办事项列表（productbacklog Item，PBI）是用来确定、定义、优先排序和估计任务的。软件的工作版本将在每次增量中进行测试和发布。每天的scrum会议确保工作按计划进行。
• FDD：这是一种模型驱动的、简短的、迭代的软件开发方法，使用五个阶段的过程：（1）开发产品模型以确定领域的广度；（2）创建需求或特性列表；（3）构建特性开发计划；（4）开发迭代特定特性的设计；（5）编码、测试，然后集成这些特性特征。FDD类似于增量软件开发方法；它也类似于XP，只是代码所有权被分配给个人而不是团队。FDD强调软件的整体架构方法，它促进第一次正确地构建特性，而不是强调持续的重构。

在文献和实践中有许多敏捷方法的变体。请注意，总会有重量级的、基于计划的软件工程方法以及敏捷方法闪耀光芒的地方。敏捷方法和基于计划的方法的结合产生了一些新方法，从业者们定义了一些新方法，这些新方法主要基于当前的组织业务需求来平衡重量级和轻量级方法所需的特性。这些业务需求，通常由一些项目涉众代表，应该并且确实推动了选择使用一种软件工程方法而不是另一种方法，或者从软件工程方法组合的最佳特性构建新方法。