软件产品架构设计

一、架构活动概述

   软件产品的架构设计是产品开发过程中最重要的活动之一（另一个重要的活动是软件需求分析过程，本文不做阐述），它是软件开发的基石。对于大多数软件公司来说，出去在产品定位本身问题外，架构设计是否成功往往是决定产品是否成功的关键。在我所从事的行业软件企业来说，公司拥有众多的行业专家，需求往往不是决定产品成败的关键。很多产品，在开发刚刚结束即被腰斩，还有一些产品由于不利用用户使用而阻碍了市场的发展，究其原因，绝大多数属于产品架构设计的失败。而产品架构设计的失败，更多在于软件产品架构设计过程缺乏有效的直到与监督。

本文仅从如何更好的开展架构设计活动进行阐述，基本不涉及或很少涉及所使用的技术特点。

二、架构活动过程

    在SEI的《软件架构实践》一书中，对于软件架构活动给出了如下的部分，包括：

    1）创建商业目标（商业案例），主要包括产品定价、定位、目标市场、业务模式、产品接口等

    2） 理解需求，主要包括系统功能需求、涉众需求、限制条件，最后形成系统质量目标

    3）选择或创建架构。包括原有同类架构分析（问题分析）

    4）架构编档。架构编档的活动定位到给后期维护者和其他涉众了解架构或者维护作为参考的依据；

    5）架构实现与验证。

    6）架构评估

   不同企业都会根据自身的特点，在其流程体系中规定特有的架构设计活动及其过程。多数企业，将商业目标作为项目立项时的基本要素，架构更多的是基于这些商业目标、基于这些软件产品的需求进行软件技术实现。因此，将架构活动整理为如下几个部分：

1） 制定架构设计目标。

   正如做任何一项活动都要目标一样，架构设计也要有自己的目标。架构设计目标是在产品的商业目标基础上，以需求为主要的技术来源，制定而成。架构设计目标是最检验架构设计活动是否成功的关键，因此架构设计目标必须符合SMART原则。目标界定以满足产品的最重要特性为基础，例如：多维分析的需求、个性化报表设计的需求等等；在这个过程中特别注意不要忽视非功能性需求，比如：产品的安全性需求、性能需求以及其他的限制条件。

   制定目标是要区分目标要求与技术方案的区别，不要把最终实现方案混淆为架构的设计目标。比如：针对企业级产品应用解决方案中，如果商业目标是满足广域网应用的业务模式，那么B/S和C/S都是技术备选方案，而不是设计目标。这里的设计目标是——满足广域网应用模式；如果商业目标是满足浏览器应用的业务模式，那么B/S就可以作为设计目标加以确定。目标的制定者谨防此类错误的产生，否则技术解决方案极有可能局限在某些目标制定者倾向的方案中，无法对未来的技术方案做出正确的评估。

2） 架构设计。

   架构设计包含两个关键的内容，其一是技术备选方案评估；其二是选定技术方案的设计（细化）。技术备选方案决定技术未来的走向，而技术人员的特质决定了技术人员习惯于选用新的技术，对公司已存在的技术总是抱有偏见，因此做好技术备选方案的评估十分的重要，它是非常关键的一环。通常技术备选方案提供两个或两个以上的技术方案进行比较优劣势分析（可以采用SWAT分析法），供决策者评估。然而，非常遗憾的看到，在实际工作过程中，技术备选方案流于形式，变成技术方案介绍会，产品失败的种子就此埋下。

技术方案设计或细化一般包含如下内容：

   a)  确定架构风格与架构模式；

   b)  架构主要应用模式分析设计；

   c)  概念模型与设计模型设计，包括：数据库设计、类设计、顺序图、活动图等等；

   d)  架构主要指标分析设计；

   e)  专项设计。将专项设计与架构设计分开考虑，专项设计指系统中较难实现的技术点或者较为复杂的业务设计。比如：系统中要实现大文件的断点续传，则断点续传是一个比较重要的技术点，需要进行专项设计。

    f)  工具设计。工具通常用来提高程序员的开发效率，虽然不是起决定性的或者必须的一环，但是良好的工具对于达成项目的时间目标非常关键。比如：采用元数据的应用模式，则需要提供元数据的编辑工具，以提高程序员的开发效率。

3） 架构编档。

   时下敏捷的思想十分流行，作为软件企业我们公司自然不能置身于外。然而，在实行敏捷的时候偏离了轨道，片面的把敏捷看成是抛弃一切流程和一切文档。流程消失了，文档消失了，感觉就像从21世纪倒退回原始时代。文档的作用包括：

   a)  帮助我们设计思考；

   b)  帮助我们改进成果；

   c)  帮助我们查找原因；

   d)  帮助使用者理解；

   e)  帮助开发者开发程序。

4） 架构实现与验证。

   架构设计并不仅仅是完成了类图或顺序图就算完成，架构实现也属于架构活动的一部分。一方面需要验证架构设计是否存在问题，一方面需要提供基于架构的实现案例，以作为架构检验和后期培训的重要参考。在这个活动中，关键一环是性能的测试。我们公司很多软件在业务设计上，在软件设计思想上似乎都很完美，然而却终死于一个问题——执行效率。执行效率的测试，需要根据软件应用情况给出关键性的指标数据，并在模拟用户的场景中进行，因为往往开发环境优异，而用户环境中存在很多无法预料的问题。

5） 架构评估。

   架构设计完成之后，是否满足产品需要就是架构评估要完成的工作。进行架构评估活动，就需要重新针对架构设计目标进行梳理，探究架构设计对目标的满足程度。架构评估的方法有很多中（可以参考《软件架构实践》一书）。情景模式的方法，比较简单易于操作。架构评估是架构活动的尾声，也是架构出厂前最后一个检验点。成败系于一线。

6） 架构重构（持续改进）。

   架构设计完成之后，不代表架构设计工作已经完成，架构设计活动从软件项目立项开始，直至产品生命期结束都存在。这个过程中根据需求变化和应用要求，进行架构的变更和架构的持续改进（重构），延续并维持架构的生命力

三、架构活动成败关键要素

   a)  是否以项目目标为主要出发点，以架构的最小化设计为第一目标。

   b)  是否在兼顾效率与质量原则基础上，才考虑架构的最优化设计。

   c)  是否着重考虑并验证了软件开发和执行效率。