软件工程中的系统文献映射研究实例-软件开发中的假设条件与哪些软件制品关联（第四部分）

之前的博客详细描述了软件工程中的系统文献映射研究方法。这里接着给出一个我曾经做过的工作作为例子，以更直观地展示这种研究类型。该研究的背景信息这里不再赘述。    

这篇博客主要介绍第三个研究问题的结果，即软件开发中的假设条件与哪些软件制品关联。

如下表所示，软件开发中的假设条件与多种软件制品关联。本研究将制品按软件开发活动分类，且采用SWEBOK建议的软件开发活动[1]（原因与研究问题二同）。虽然一种类型的制品可能与一个或多个软件开发活动关联，但此分类中，本研究仅考虑与制品关联的主要活动（即该产生和管理该制品的活动，如需求和需求工程）。这样考虑的原因是研究问题三关注的是哪些软件制品与假设条件关联，而不是软件开发活动和制品之间的关系。例如关注需求是否与假设条件关联，但并不关注文献中的需求是在需求工程中讨论还是在其他的软件开发活动中讨论。为使分类更易理解，本研究在软件开发活动的基础上进一步针对制品名字进行分类。此外，虽然研究问题二和三的结果都根据软件开发活动分类，它们无法合并，因为研究问题三的结果仅包括文献中显式地讨论假设条件及其相关制品的部分，而研究问题二的结果范围更广，即包括在特定的软件开发活动中制定假设条件但未提及相关制品的情况。最后，因一篇文献可能提到与假设条件关联的多种制品，故此类文献可能被分类到下表的多种类型中。

 

软件开发活动	数量（%）	软件制品	数量（%）
需求工程	72 (53.7%)	“其他”：需求、功能（点）、特征、用例、需求决策、用户反馈、目标、功能性协议、需求原型	69 (51.5%)
		“文档”：需求文档、特征文档、功能文档、用例文档、用户文档、产品文档、设备文档、领域文档、行为文档、安全控制文档	15 (11.2%)
		“模型”：需求模型、目标模型、特征模型、用例模型、领域模型、行为模型	10 (7.5%)
		“场景：需求场景、质量属性场景、使用场景	6 (4.5%)
软件设计	96 (71.6%)	“构件-接口”：构件、COTS产品、构件服务、构件协议、端口、构件模型、接口、接口事件、API、API使用模式、构件追溯、服务、模块、包	80 (59.7%)
		“决策”：系统决策、设计决策、模型决策	25 (18.7%)
		“体系结构”：体系结构、体系结构视图、体系结构解决方案	18 (13.4%)
		“其他”：设计模型、数据流、控制流、设计模式、设计协议、设计声明、设计对象、设计人物角色	7 (5.2%)
		“文档”：设计文档、体系结构文档、构件文档、服务文档、方面文档	6 (4.5%)
		“方面”：方面、方面属性模型	4 (3.0%)
软件构造	31 (23.1%)	“代码”：代码、代码意见、代码注释、实现决策、类、线程	31 (23.1%)
		“文档”：程序文档、数据文档	2 (1.5%)
软件测试	5 (3.7%)	漏洞、测试计划	5 (3.7%)
其他	16 (11.9%)	风险、组织决策、管理决策、计划、任务、环境模型、环境文档、版本控制信息、系统日志、过程模型、产品模型	16 (11.9%)

 

下表提供九种假设条件与其他类型的制品的关系类型。

 

关系	描述
A为B而制定	假设条件为其他类型的制品而制定（反之亦然）。
A基于B	假设条件的制定基于其他类型的制品（反之亦然）。
A包含于B	假设条件是其他类型的制品的构成部分。
A等同于B	假设条件等同于其他类型的制品。
A导致B出现问题	假设条件导致其他类型的制品出现问题（反之亦然）。
A导致B改变	假设条件导致其他类型的制品改变（反之亦然）。
A帮助管理B	假设条件帮助管理其他类型的制品（反之亦然）。
若A出现问题则对B产生消极影响	若假设条件出现问题（如失效）则对其他类型的制品产生消极影响（反之亦然）。
A与B关联	假设条件与其他类型的制品有关联，但未显式陈述其关系类型。

 

为详细描述假设条件与其他类型的制品的关系，以下提供多个具有代表性的例子。请注意假设条件的概念较为主观且依赖环境。此处提供例子的目的为解释这些关系类型，而不是区分假设条件和其他类型的概念。因此以下例子未包含其环境信息。

1. 需求工程

在文献[2]中，假设条件为需求而制定（即A为B而制定）。一个该假设条件的例子为：假设系统在工作时间内可用。在文献[3]中，假设条件分布在多个质量属性场景中（即A包含于B）。一个该假设条件的例子为：假设存在子系统负责接收紧急呼叫并将其转发至可用的协调者。该假设条件定义于两个质量属性场景中。在文献[4]中，作者提到无效的假设条件可能导致需求的变更；而操作领域的变化可能导致假设条件的变化（即A导致B改变）。

2. 软件设计

在文献[5]中，体系结构假设条件可能促进设计决策的制定（即A帮助管理B）。一个该假设条件的例子为：假设将有一个独立系统来处理信息更新，且该系统针对数据包将采用优先队列。该假设条件用于缩小解空间以帮助架构师制定体系结构设计决策。在文献[6]中，作者定义假设条件为隐式的设计决策（即A等同于B）及其原理和环境（即A基于B）。此文献列举的假设条件包括管理的假设条件、组织的假设条件、技术的假设条件。在文献[7]中，作者指出系统的设计决策基于环境的假设条件（即A基于B）。

3. 软件构造

在文献[8]中，假设条件为代码而制定（即A为B而制定）。一个该假设条件的例子为：API客户端不应调用方法M。在文献[9]中，作者建议将假设条件的识别和描述作为程序文档的一部分（即A包含于B）。在文献[10]中，假设条件被用于建模线程的行为（即A帮助管理B）。一个该假设条件的例子为：若线程i在读取模式下持有锁，则其他线程不可改变x。

4. 软件测试

在文献[11]中，案例研究的结果显示修复漏洞是导致技术的假设条件失效的一个重要原因。十三个失效假设条件中的八个由修复漏洞导致（即A导致B出现问题）。一个该假设条件的例子为：假设两个系统在任何情况下均不影响彼此。在文献[12]中，假设条件可帮助寻找漏洞（即A帮助管理B），且特定类型的假设条件应被视为一种待修复的漏洞（即A等同于B）。

5. 其他

在文献[13]中，无效的假设条件可能增加系统风险（即若A出现问题则对B产生消极影响）。对假设条件和需求之间的关系建模是预测系统风险的途径。在文献[14]中，产品模型和过程模型中均含假设条件（即A包含于B）。一个该假设条件的例子为：假设产品的范围。

参考文献

[1] P. Bourque and R.E. Fairley. Guide to the Software Engineering Body of Knowledge (SWEBOK (R)): Version 3.0. IEEE Computer Society Press, 2014.

[2] V. Page, M. Dixon, and I. Choudhury. Security risk mitigation for information systems. BT Technology Journal, 25(1): 118-127, 2007.

[3] D.V. Landuyt, E. Truyen, and W. Joosen. Documenting early architectural assumptions in scenario-based requirements. In: Proceedings of the Joint 10th Working IEEE/IFIP Conference on Software Architecture and 6th European Conference on Software Architecture (WICSA/ECSA), Helsinki, Finland, pp. 329-333, 2012.

[4] A. Miranskyy, N. Madhavji, M. Davison, and M. Reesor. Modelling assumptions and requirements in the context of project risk. In: Proceedings of the 13th IEEE International Conference on Requirements Engineering (RE), Paris, France, pp. 471-472, 2005.

[5] D.V. Landuyt, E. Truyen, and W. Joosen. On the modularity impact of architectural assumptions. In: Proceedings of the 2012 Workshop on Next Generation Modularity Approaches for Requirements and Architecture (NEMARA), Potsdam, Germany, pp. 13-16, 2012.

[6] R. Roeller, P. Lago, and H. van Vliet. Recovering architectural assumptions. Journal of Systems and Software, 79(4): 552-573, 2006.

[7] C. Landauer. Wrapping architectures for long-term sustainability. In: Proceedings of the 2nd IEEE International Workshop on Software Evolvability (SE), Philadelphia, PA, USA, pp. 44-49, 2006.

[8] M. Feilkas and D. Ratiu. Ensuring well-behaved usage of APIs through syntactic constraints. In: Proceedings of the 16th IEEE International Conference on Program Comprehension (ICPC), Amsterdam, The Netherlands, pp. 248-253, 2008.

[9] M.M. Lehman and J.F. Ramil. Rules and tools for software evolution planning and management. Annals of Software Engineering, 11(1): 15-44, 2001.

[10] C. Flanagan, S.N. Freund, and S. Qadeer. Thread-modular verification for shared-memory programs. In: Proceedings of the 11th European Symposium on Programming (ESOP) Held as Part of the Joint European Conferences on Theory and Practice of Software (ETAPS), Grenoble, France, pp. 262-277, 2002.

[11] I. Ostacchini and M. Wermelinger. Managing assumptions during agile development. In: Proceedings of the 4th Workshop on SHAring and Reusing architectural Knowledge (SHARK), Vancouver, BC, Canada, pp. 9-16, 2009.

[12] S. Zschaler and A. Rashid. Aspect assumptions: A retrospective study of AspectJ developers' assumptions about aspect usage. In: Proceedings of the 10th International Conference on Aspect-Oriented Software Development (AOSD), Porto de Galinhas, Pernambuco, Brazil, pp. 93-104, 2011.

[13] A. Miranskyy, N. Madhavji, M. Davison, and M. Reesor. Modelling assumptions and requirements in the context of project risk. In: Proceedings of the 13th IEEE International Conference on Requirements Engineering (RE), Paris, France, pp. 471-472, 2005.

[14] D. Klappholz and D. Port. Introduction to MBASE (Model-Based (System) Architecting and Software Engineering). Advances in Computers, 62: 203-248, 2004.