寒假生活
读《软件构架实践》7-9章后感
在了解了构架的商业方面、构架视图和结构、质量属性等知识，这部分内容旨在构架的设计以及当构架逐渐形成时应该做什么。软件架构的设计是指通过一系列的设计活动，获得满足系统功能性需求（简称FR），并且符合一定非功能性需求（简称NFR，与质量属性有相似涵义）约束的软件架构模型。软件架构设计过程的本质在于：将系统分解成相应的组成成分（如构件、连接件），并将这些成分重新组装成一个系统。现阶段，软件架构设计方法大多侧重对系统NFR的考虑，往往和软件架构分析方法结合使用，希望能够在软件生命周期前期发现潜在的风险。
许多项目都是在回顾时，才发现问题出在结构上。因结构的局限性，付出很多不必要的时间和精力。在体系设计上付出一天努力解决的问题，在以后阶段可能要多付出几天到十几天也不一定能解决。一个有规范，有构造思想指导，以构架为基础的开发小组在如今的软件产品需求复杂、内容丰富、变更频繁的情况下更能少走弯路，快速而有效的解决问题。
书上介绍了ADD软件构架方法，但还有一些其他同样比较经典的方法：Bosch方法、基于架构的设计（ABD）方法、面向特征的领域分析（FODA）方法、面向产品线的抽象规范与转换（FAST）方法、面向构件的平台架构（COPA）方法、面向特征的重用FORM方法、质量驱动的架构设计与质量分析QADA方法、KobrA方法等。他们在上下文、用户、内容和确认等方面有很多异同点。演变交付生命期很像我们之前学习的瀑布模型，他交代了开发流程中获得客户和用户反馈、发布最终版本前几个版本进行迭代。
很久以前，课上有提到过编写文档的重要性，当完成一个庞大的软件构架，设计师能不能看懂就要看构架文档是否表述明了了。构架文档采用视图的概念将其简单化，在此基础上，可对行为、接口进行编档，还有就是面向涉众编档。这一点正是我需要加强训练的地方——文档。