软件制品可追溯性的形式化建模与分析

李建清，蒋建民

(成都信息工程大学软件工程学院，四川 成都 610000)

1102418305@qq.com;jjm@fjnu.edu.cn

1 引言(Introduction)

在软件生命周期过程中，常常会产生基于文本的需求、需求模型、设计模型、源代码、测试用例、各种附加文档等复杂多样的软件制品。良好的软件制品可追溯性的潜在好处是更集中于开发、更低的维护成本、更清晰的文档和更精确的变更影响分析。针对软件制品可追溯性已经研究多年，然而在管理可追溯性时，从业者得到的科学文献支持很少，有必要探索如何构建更好的可追溯性模型。一个好的可追溯性模型不仅可以保证各类软件制品之间的可追溯性关系以及这些软件制品内部元素之间的关系，而且还支持定制，并允许使用扩展性来定义新的可追溯性链接类型。我们研究的可追溯性模型完全具有这些性质。

可追溯性是描述和跟踪软件制品生命周期的能力，通常存在两种类型的软件制品可追溯性模型，一种是非形式化的，而另一种是形式化的。我们专注于形式模型，并使用形式方法来探索可追溯性。目前已有一些研究使用形式化方法建模和分析可追溯性，但这些与我们的工作完全不同。传统的形式化模型通常采用行为模型，例如Petri网、进程代数、迁移系统。根据统一建模语言UML(Unified Modeling Language)和系统建模语言SysML(Systems Modeling Language)，软件系统模型分为行为模型和结构模型。我们认为结构模型足以对可追溯性进行建模和分析，因为可追溯性关系是一种结构关系。此外，如果用行为模型描述可追溯性，必须使用复杂的可达性算法来分析可追溯性，需要考虑状态爆炸问题，从而花费较大代价。在本文中，我们提出了一种形式化的可追溯性模型，称为“结构模型”，用于建模和可视化可追溯性，并基于该结构模型讨论了一些可追溯性的分析方法，比如变更影响、制品和版本分析，最后实现了基于结构模型的支持工具并用实验证明我们的新方法是有效的。

本文其余部分的结构如下：第2部分是可追溯性模型；第3部分是可追溯模型的组合；第4部分定义了可追溯性；第5部分是可追溯性分析；第6部分是案例研究和我们的支持工具介绍；第7部分是相关工作；第8部分总结了论文。

2 可追溯性模型(Traceability model)

该示例表明，结构模型可以指定软件系统中各种制品之间的关系。它可以直接使用原来的关系来表示用例模型之间的内部关系(比如include和extend)及类之间的关系(比如aggregation)。一旦结构模型明确了系统生命周期过程中模型的模型元素之间的关系，我们就可以从其结构的角度来分析该系统。

证明：这个命题直接可得。

显然，在一个结构模型中，关系链的数量大于等于依赖链的数量。

3 可追溯性模型的组合(Composition of traceability model)

复杂的软件系统包含许多制品，并分为由不同团队开发的多个子系统。每个团队都需要构建自己的软件制品可追溯性系统。一旦整个系统完成，所有的制品必须放在一起，并组成完整的可追溯性系统。因此，有必要讨论可追溯性的组合问题。

证明：这些命题直接可得。

这个命题表明，结构模型的组合具有封闭性、交换性和结合性。

4 可追溯性的定义(Definition of traceability)

软件制品的可追溯性已被认为是支持软件开发和维护过程中各种活动的重要质量因素。软件生命周期过程通常包含顺序阶段：需求、设计、实现、测试和维护，每个阶段都存在各种制品。一般认为，下一阶段的制品(模型元素)依赖于前一阶段的制品。文献[11]和文献[12]中的可追溯性思想侧重于需求和代码(实现)阶段之间的依赖关系。我们扩展了这些想法，并提出了以下横向和纵向可追溯性的形式化定义，并进一步给出了可追溯性的定义。

这里，水平可追溯性考虑需求和维护阶段之间的直接和间接依赖关系，而垂直可追溯性则侧重于模型元素的版本变化，即模型元素的版本号大于或等于其依赖模型元素，如图2所示。显然，虽然依赖链是直接的，但它们可以基于有向图反向遍历。因此，向前可追溯性和向后可追溯性包含在此定义中。定义不仅考虑了模型内部的可追溯性，还考虑了多个模型之间的可追溯性。

图1 系统中的偏序关系Fig.1 The partial relationships in a system

图2 水平方向和垂直方向的可追溯性Fig.2 Horizontal and vertical traceability

定理4.1表明可追溯性在一定条件下是可组合的。

5 可追溯性分析(Traceability analysis)

基于结构模型，这里介绍了一些可追溯性分析方法。

5.1 变更影响(覆盖)分析

在大型软件项目中，变更影响分析和变更覆盖分析在控制软件演化方面起着重要作用。一旦创建、修改和删除模型元素，因为可能存在许多与该模型元素直接或间接相关的模型元素，因此相关的模型元素也可能会发生变化。我们的方法提供了更精确的变更影响分析，支持变更替代识别、消除误报和变更一致性检查。

模型元素的影响集包含直接或间接依赖于该模型元素的元素。该定义给出了一种计算模型元素影响集的方法。由于结构模型形成一个有向图，其中模型元素是顶点，包含或依赖关系是边，可以使用图遍历算法轻松计算任何模型元素的影响集，我们的工具已经实现了这个功能(见第6部分)。

图3 可追溯性管理Fig.3 Managing traceability

5.2 制品分析

在一个软件产品线中，制品的多个版本共存并同时在多个产品中使用，需要跟踪哪个产品使用哪个版本。显然，存在一些用于构建多个产品的制品。事实上，每一个新产品都对应一个新版本号，但其中也包含许多版本保持不变的制品(请注意，这样的版本号对应于我们的可追溯性模型中的初始版本号，不是我们的可追溯性中的最终版本号)。

在我们的解决方案中，无论何时创建产品，都可以跟踪任何产品的所有制品。当一个产品发布时，需要创建一个模型元素，其中包含代码元素和相应版本号的各种文档，以及一些未更改的旧版本制品。例如，如果某些需求不需要改变，而新产品满足了这些需求，我们可以根据新产品中包含的旧模型元素的直接或间接依赖关系来追溯这些需求。由于版本号通常是递增分配给新模型元素的，因此产品模型元素的版本号大于或等于产品中包含的制品的版本号。

证明：这个命题直接可得。

这个命题说明，在可追溯的管理系统中不存在孤立的软件制品，即孤立的软件制品是不可追溯的。

5.3 版本分析

作为可追溯性最重要的工作之一，版本控制就是管理代码等制品的变更和版本，并解决合并冲突和相关异常。在本部分中，我们将分析软件制品的版本可追溯性。

证明：根据定义4.1(2)，新模型元素必须依赖于旧模型元素，并且新模型元素的版本号大于或等于旧模型元素的版本号。此外，同时创建多个模型元素，这些模型元素具有相同的版本号。因此，结果显然成立。

图4 异常的依赖关系和版本号Fig.4 Abnormal dependencies and version numbers

为了构建基于结构模型的可追溯性管理系统，我们开发了一款Web端名为JLTool的工具。该工具主要由两个完整的模块组成，一个模块是绘制UML图等各种图，创建模型元素之间的可追溯性关系(包括自动化或半自动化UML图导入和可追溯性链接生成)；而另一个是执行可追溯性分析，如变更影响(覆盖)分析、制品分析和版本分析。该工具可以从以下地址使用：http：//219.151.152.164：3000/。我校软件工程专业的学生正在使用该工具进行软件开发实验。

6 案例研究(Case study)

在本部分中，我们使用一个简单的地址簿系统演示本文中的结果。本案例(http：//www.cs.gordon.edu/courses/cs211/AddressBookExample/)由美国Gordon学院计算机科学教授Russell C.Bjork开发。在初始版本中，简单的地址簿系统包含以下制品：10 个需求项、15 个用例、11 个类、15 个序列图和11 个代码片段。每个制品都被视为一个模型元素。在我们的工具中，不同类型的模型元素可以包含不同的内容主体。例如，我们的工具提供了一个需求项的对话框，该对话框用于输入需求项的具体文本内容。类似地，我们的工具可以从XMI格式的文件中手动绘制或完全导入UML图作为模型元素，例如，每个序列图都是一个模型元素(可以通过工具Help中的Case study导入该案例)。

图5 变更影响分析Fig.5 Changing impact analysis

7 相关工作(Related work)

软件追溯管理问题得到了广泛研究，大多数研究使用非形式化方法来探索如何管理软件生命周期过程中的可追溯性。我们的工作涉及形式化方法，该方法有助于为软件制品可追溯性提供严格的语义，以便对可追溯性进行建模、设计和推理。因此，我们在这里只讨论最相关的作品。WEN等人使用称为行为树的形式化模型来表示功能需求，以确保变更管理的完整性并自动获取记录设计变更历史的进化设计文档。在文献[17]中，ERATA等人介绍了一种新方法及称为Tarski的支持平台，该方法以交互方式表示可追溯性的语义，并使用户能够根据项目特定需求严格配置系统。GOKNIL等人提出了需求元模型，包括具有在一阶逻辑中指定的形式语义的关系类型。BROY区分了逻辑制品内容、制品内容表示及其物理表示，并定义了制品内容块的概念。在上面提到的工作中，其可追溯性语义很难处理软件制品的多对多关系，而我们的方法没有限制。

在文献[19]中，GOKNIL等人提出了一种在工具支持下生成和验证需求及架构之间跟踪的方法。DRIVALOS等人提出了一种可追溯性元建模语言(TML)，该语言用于在高抽象级别上构建和维护严格的可追溯性元模型。PAIGE等人提出了一种在基于模型的工程中识别、定义和实现语义丰富的跟踪链接的方法。DI等人提出了一种基于模糊逻辑自动生成需求可追溯性矩阵的方法，该方法用于处理那些可能对需求可追溯性的确定产生负面影响的不确定性。SCHWARZ等人介绍了基于图的方法来形式化和实现软件工程项目中的可追溯性信息，旨在实现基于需求的软件重用。SEIBEL等人提出了一种综合的可追溯性方法，该方法针对模型驱动的工程和全局模型的能力方法，以动态分层的大型模型的形式进行管理。HOLTMANN等人在基于模型的开发上下文中给出了可追溯性术语的定义，并开发了一组术语，使我们能够描述如何使用可追溯性，以及跟踪链接具有哪些属性。这些研究与我们的工作完全不同。

8 结论(Conclusion)

我们展示了如何在各种管理操作下保证可追溯性的正确，并提出了使用形式化方法构建、分析和可视化整个软件生命周期过程中的可追溯性的新的解决方案。我们开发了一个支持工具，用于促进不同形式的自动化分析，例如变更影响、制品和版本分析。该工具还可以帮助工程师半自动地建立和维护可追溯性信息。在本文中，由于我们关注的是管理追溯性的正确性，因此没有考虑如何建立一个存储库来存储追溯信息，但是我们的工具采用了一些节省存储空间的解决方案。在未来的工作中，我们将探索如何更有效地存储软件制品和可追溯性信息，并完善JLTool工具，希望使其成为真正的CASE工具。