软件架构假设条件与其他类型软件制品的区别

    上一篇博客分析了软件架构假设条件的基本特征。根据这些特征，特别是其主观性的特征，多项研究指出难以区分假设条件和其他类型的软件制品。例如Roeller等人[1]讨论了架构假设条件、需求、设计决策、约束的区别。Roeller等人认为研究者和实践者在软件开发中常常交替地使用这些术语从而导致不一致性[1]。因此，同样的信息在某个环境中可能是一个假设条件，而在另一个环境中可能是一个完全不同类型的制品。除非涉众以特定方式表达该信息（如句子中包含“假设条件”一词），否则难以在不了解环境的情况下判断该信息是否是一个假设条件。 

    在软件开发中明确表达假设条件是必要的，然而在实践中往往难以实现，且涉众常常需要判断某信息是假设条件还是其他类型的制品。为了帮助涉众区分假设条件与其他类型的制品，此处提供以下六条经验。需要说明的是，虽然这些经验可以辅助涉众对假设条件的判断，但目前尚不存在确切的判断规则。 

    （1） 尽管其他类型的制品可能也包含不确定性，但不确定性并非其核心。例如当提到一个设计决策时，涉众一般不会关注该决策是否不确定，而更多地关注该决策所解决的问题。相反地，假设条件主要为应对软件开发中的不确定性而存在。 

    （2） 假设条件和其他类型的制品在内容上有差异。例如设计决策的内容往往关于如何解决一个问题，而假设条件的内容更多关于某事物的正确性、适应性、重要性等。 

    （3） 关注于情境而不仅是内容。虽然我采集了大量假设条件的例子。例如Page等人[3]给出的例子为：“系统在正常工作时间内总是可用”；Landuyt等人[2]给出的例子为：“存在一个子系统负责接收紧急通讯并转发至可用的协调者”；Flanagan等人[4]给出的例子为：“若线程i在只读模式下持有锁，则其他线程不能改变x”。但若仅阅读这些例子本身，很难识别出它们是假设条件。然而，若阅读这些例子的情境信息，则可解释为什么上述研究者会视它们为假设条件而不是其他类型的制品（如需求）。 

    （4） 所有假设条件均具有不确定性的特征。若某事物为确定的或有足够充分的证据支持其有效性，则它不是一个假设条件。除了不确定性之外，假设条件是被接受或认可为真的知识。因此若在某信息中发现此特征，则该信息更倾向于是一个假设条件。 

    （5） 涉众应在他们的项目中就什么是假设条件达成一致。除了关注假设条件的属性外，涉众还应考虑或向其他涉众解释为什么某信息是假设条件，而不是其他类型的制品。 

    （6） 某些情况下假设条件和其他类型制品间的界限较模糊。涉众应关注于在团队内部就某条信息是否为假设条件达成一致，而不是一定要寻求所谓“正确”的答案。若全部或大部分涉众均同意某陈述为假设条件，则可在项目中将其视为假设条件来管理。在项目的后续阶段，若涉众发现了更多的证据，则可以对其所属制品类型做相应调整。 

 

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

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

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

[4] 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), Grenoble, France, pp. 262-277, 2002.