接着很久以前的一篇博客（浅谈Architectural Assumption（软件架构设计的假设条件）（1））继续聊软件架构设计的假设条件。
首先还是简单介绍软件架构。
近年来，软件架构已逐渐发展成为软件工程领域的一个重要研究方向[1]。软件架构代表“the fundamental concepts or properties of a system in its environment embodied in its elements, relationships, and in the principles of its design and evolution”[2]。任何系统均有架构[3]。目前存在多种关于软件架构的定义。例如Bass等[3]认为软件架构是抽象层次较高的设计，即在功能性、非功能性和商业性需求间做复杂的权衡。 软件架构的主题在学术界和工业界都有较长的历史[4]。对它的认知经历了从初期的系统结构和行为（即通过连接器交互的构件）到后期的软件架构知识概念的演化[5]。后者不仅重视架构的最终结果，同时重视涉众如何达成最终结果的过程（即架构知识管理）[6][7]。
研究者和实践者近年来普遍强调架构知识及其管理（如归档、共享、重用）的重要性[5]。管理架构知识的好处有多种[5]，包括（1）减少软件开发中的知识蒸发；（2）减少涉众之间的误解以及低效的交流；（3）促进项目团队对架构乃至整个系统的理解；（4）促进系统分析（如设计决策的影响分析）。
根据以前对软件开发中的假设条件的定义，我进一步定义软件架构假设条件为：在没有足够证据支持的情况下，被接受或认可为真的架构知识。例如，某涉众可能假设“系统每天的访问量会超过100万”。当这个架构假设条件中的不确定性被移除时，则该假设条件可能被移除或者转换成其他的制品。如果系统每天的访问量真实超过100万，则该假设条件转换为一个需求。
类似其他类型的假设条件，架构假设条件具有的特征描述如下。
主观性。许多研究者和实践者指出软件开发中假设条件的主观性特征（即判断某信息是否是一个假设条件具有主观性）。这也是涉众对假设条件概念可能有不同理解的主要原因。例如Roeller等研究者[8]指出：对某涉众来说是一个假设条件的信息，在其他涉众看来可能是一个设计决策。
演化特性。假设条件可能随时间演化[9]。例如在软件开发中，一个有效的假设条件可能变为无效（反之亦然），或者一个假设条件可能转化为其他的制品（反之亦然）。
环境依赖特性。假设条件依赖于环境[10]。例如同样的一个假设条件可能在一个项目中有效，但因为环境的改变在另一个项目中无效，或者某个项目中的一个假设条件在另一个项目中并非假设条件。演化特性和环境依赖特性可能是未被妥善管理的假设条件会在软件开发中导致多种问题的关键原因。例如在ARIANE 5中复用了ARIANE 4中的一个假设条件，而该假设条件在ARIANE 5中无效，从而导致了ARIANE 5的灾难[11]。
与多种制品关联的特性。在软件开发中假设条件并非独立存在，而是与不同类型的软件制品关联。例如当管理软件设计中的假设条件时，这些假设条件往往会和需求、设计决策、构件等关联[12]。
假设条件管理目前仍处于较不成熟的阶段。以下给出两个例子。尽管已经存在特定的方法和工具（如[8][13]）以管理假设条件，但仍然缺乏对假设条件管理整体的深入理解。此外，假设条件管理应为团队协作的工作，即不同类型的涉众应参与[14]。然而，目前并不清楚谁应该参与以及如何参与假设条件管理。
假设条件可以被自动化管理或人工管理。自动化管理中一般采用形式化的方法和工具（如涉众并不制定假设条件，而依赖于这些方法和工具自动化地制定假设条件）。一个代表性的例子是assume-guarantee reasoning的方法（如[15][16][17][18][19][20]）。另一方面，假设条件人工管理指以涉众为核心的管理（如涉众使用方法和工具以制定和归档假设条件）[8][21][22]。
[1] E.J.W. Jr, J.E. Robbins, N. Medvidovic, and R.N. Taylor. Software architectures: Foundation of a software component marketplace. In: Proceedings of the 1st International Workshop on Architectures for Software Systems (ISAW), Seattle, WA, USA, Springer, pp. 276-282, 1995.
[2] ISO. ISO/IEC/IEEE Std 42010-2011, Systems and Software Engineering – Architecture Description, 2011.
[3] L. Bass, P. Clements, and R. Kazman. Software Architecture in Practice, 3rd edition, Addison-Wesley Professional, 2012.
[4] P. Clements and M. Shaw, "The Golden Age of Software Architecture" Revisited. IEEE Software, 26(4): 70-72, 2009.
[5] R. Capilla, A. Jansen, A. Tang, P. Avgeriou, and M.A. Babar. 10 years of software architecture knowledge management: Practice and future. Journal of Systems and Software, 116(6): 191–205, 2015.
[6] J. Bosch. Software architecture: The next step. In Proceedings of the 1st European Workshop on Software Architecture (EWSA), St Andrews, UK, pp. 194-199, 2004.
[7] P. Kruchten, P. Lago, and H. van Vliet. Building up and reasoning about architectural knowledge. In: Proceedings of the 2nd International Conference on Quality of Software Architectures (QoSA), Västerås, Sweden, pp. 43-58, 2006.
[8] R. Roeller, P. Lago, and H. van Vliet. Recovering architectural assumptions. Journal of Systems and Software, 79(4): 552-573, 2006.
[9] G.A. Lewis, T. Mahatham, and L. Wrage. Assumptions Management in Software Development. Technical Report, CMU/SEI-2004-TN-021, 2004.
[10] C. Yang, P. Liang, P. Avgeriou, U. Eliasson, R. Heldal, and P. Pelliccione. Architectural Assumptions and their Management in Industry – An Exploratory Study. In: Proceedings of the 11th European Conference on Software Architecture (ECSA), Canterbury, UK, pp. 191-207, 2017.
[11] ARIANE 5 Flight 501 Failure Report by the Inquiry Board. 1996. http://sunnyday.mit.edu/accidents/Ariane5accidentreport.html
[12] P. Lago and H. van Vliet. Explicit assumptions enrich architectural models. In: Proceedings of the 27th International Conference on Software Engineering (ICSE). St Louis, Missouri, USA, pp. 206-214, 2005.
[13] E. Denney and B. Fischer. A verification-driven approach to traceability and documentation for auto-generated mathematical software. In: Proceedings of the 24th IEEE/ACM International Conference on Automated Software Engineering (ASE), Auckland, New Zealand, pp. 560-564, 2009.
[14] R. Seater, D. Jackson, and R. Gheyi. Requirement progression in problem frames: Deriving specifications from requirements. Requirements Engineering, 12(2): 77-102, 2007.
[15] C. Blundell, D. Giannakopoulou, and C.S. Pǎsǎreanu. Assume-guarantee testing. ACM SIGSOFT Software Engineering Notes, 31(2): Article No. 1, 2005.
[16] J.M. Cobleigh, G.S. Avrunin, and L.A. Clarke. Breaking up is hard to do: An evaluation of automated assume-guarantee reasoning. ACM Transactions on Software Engineering and Methodology, 17(2): Article No. 7, 2007.
[17] D. Giannakopoulou, C.S. Păsăreanu, and H. Barringer. Component verification with automatically generated assumptions. Automated Software Engineering, 12(3): 297-320, 2005.
[18] S. Chaki, E. Clarke, N. Sharygina, and N. Sinha. Verification of evolving software via component substitutability analysis. Formal Methods in System Design, 32(3): 235-266, 2008.
[19] C. de la Riva and J. Tuya. Automatic generation of assumptions for modular verification of software specifications. Journal of Systems and Software, 79(9): 1324-1340, 2005.
[20] J.M. Cobleigh, D. Giannakopoulou, and C.S. Păsăreanu. Learning assumptions for compositional verification. In: Proceedings of the 9th International Conference on Tools and Algorithms for the Construction and Analysis of Systems (TACAS) Held as Part of the Joint European Conferences on Theory and Practice of Software (ETAPS), Warsaw, Poland, pp. 331-346, 2003.
[21] C.B. Haley, R.C. Laney, J.D. Moffett, and B. Nuseibeh. Using trust assumptions with security requirements. Requirements Engineering, 11(2): 138-151, 2006.
[22] A. Tang, Y. Jin, and J. Han. A rationale-based architecture model for design traceability and reasoning. Journal of Systems and Software, 80(6): 918-934, 2007.