1 基于架构的软件设计方法概念
关键词：ABSD、自顶向下、递归迭代、与需求同步、设计元素、视角与视图、用例和质量场景、预期和非预期等。
总的来讲，ABSD方法分为如下六个大的阶段：
1）体系结构需求阶段
相比传统软件系统设计，架构设计在需求获取、分析之后展开不同，基于体系结构的软件架构设计，将架构设计工作提前到与需求同步，在需求阶段即开始展开体系架构设计，可以更好的完成设计工作，更好的支持软件复用。
ABSD方法在需求阶段的工作包括需求获取、标识构件、架构需求评审。需求获取用于提取系统相关的功能、质量属性，目标为服务商业和用户及开发人员目标。之后需要对需求进行分析，生成类图，对类进行分组，将类打包为构件，从而完成标识构件的工作。这个过程是不断迭代的过程。完成标识后，还需要组织相关人员（分析、用户、设计、测试等）对体系结构需求和构件进行评审，确定类是否合理，划分是否合理，构件合并是否合理等。
2）体系结构设计阶段
设计阶段的工作包括选择体系结构风格、映射构件、分析构件作用、产生体系结构、设计评审等步骤。选择合理的架构风格是首要工作。这可以统一大家对系统的基础理解。注意，这个步骤的结果并不一定是完美的，可能在后续完善迭代过程中完善。有了组织结构风格的理解后，就需要将标识的构建映射到体系结构中，产生一个中间结构。因为构件并不是独立的，之间有交互，有联系，所以还要分析他们的作用关系，在理清作用关系的基础上就可以精化体系结构，产生一个初步的体系结构，用于评审。这个评审需要邀请独立于系统开发人员的外部人员进行。
3）体系结构文档化
因为体系结构是抽象的，概念上的，所以要与开发人员、实现人员达成一致理解，还需要进行文档化工作。这个阶段输出体系结构规格说明文档和测试体系结构需求的质量设计说明书。文档需要从使用者的角度出发进行编写，需要是形式化的，有比较严格约束的。
4）体系结构复审
在开始编码实现之前，还需要对体系结构文档进行复审，用于识别缺陷和风险。这主要由外部专家和领域专家甚至用户代表来参加。设计人员可以大家一个最小化可运行系统来评估和测试体系架构，最终确定是否满足功能、质量需求，层次是否清晰，构建是否合理，表达是否明确等。
5）体系结构实现
实现阶段的工作主要包括构件分析和设计、构件实现、构件组装、系统测试等。构件的设计和实现要满足体系结构文档中有关构件的约束要求。测试不仅要进行功能测试，还需要进行性能测试，以满足整体要求。
6）体系结构演化
需求可能发生变化，体系结构要进行演化。演化过程包括需求归类、制定演化计划、构件变动、更新构件的相互作用、构件组装与测试、技术评审。整个过程还是比较容易理解的。评审后如果修改测试不符合需求，还需要迭代优化。
对上述过程主要是理解。在理解的基础上应用于实际系统开发中。从上面的介绍中我们可以看到，整个过程还是比较严谨细致的，关键问题是实际中执行的情况如何。
2 实际系统构建过程中的应用
仍然以前述某电力系统项目为例。
体系结构需求分析阶段的工作包括获取需求，生成类图，对类进行分组，打包成构件，对需求进行评审，产生领域模型。针对上述项目，从业务角度来看，包括了会议管理（包括传统网络会议和电话会议），通信管理（包括异构网络互联互通、多通信手段的无缝衔接，以打破信息孤岛），数据管理（各类数据的融合，共同服务业务流程，包括线路数据、定位数据、设备数据等），设备管理（各类设备的接入支持，采样支持）等。从技术上看，综合了多媒体音视频技术，网络技术，通信技术，大数据技术、云计算技术等。这些主要服务功能性需求。在需求阶段，需要对各种技术需求进行梳理，并根据耦合内聚的情况，对设计的相关类进行分组。除了功能性需求外，非功能性需求更是需要投入精力仔细研究，对本项目来讲，可靠性、安全性都是重要的特性要求，而且还涉及一定的性能要求，这些在需求阶段都需要进行边界约束，从而为后续设计和测试阶段提供依据。
设计阶段，需要选择风格，映射构件，分析构件的相互作用，对设计评审，产生体系结构。在需求工作做的足够充分的基础上，才能合理的设计架构。风格的选择是至关重要的第一步，影响后续工作的大方向。在本系统中，考虑到业务涉及的面比较广，底层支撑技术较为全面，有一定深度要求，因此总体采用分层风格，以便更好的对系统进行抽象建模。而且，层次结构兼具灵活性和统筹性，既能方便大家都系统达成一致的理解，也能方便扩展和变通具体的实现方案，在领域内被广泛的使用，所以这一选择得到了团队的一致认可。
具体来讲，将系统划分为硬件、操作系统（驱动）、平台、网络+数据、业务、展示等几个层次，每一层依赖下层，对上层提供需要的支撑能力。比如，操作系统层面提供硬件资源管理，提供对容器和虚拟化的支持。平台层，可以构建对业务层其关键支撑的技术框架，包括多媒体的采集渲染，数据的编解码支持，网络通信的支持，异步事件的支持，开发框架的支持等。总的来讲，这部分既是独立技术的排列，扩展系统的支撑能力，也是技术模型的聚合，关注点分离，方向的约束，是在对需求进行全面分析基础上做出的。而数据和网络层则更加聚焦面向业务，等到业务层面，其需要的各类技术支撑，在底层都能够得到确认，也基本证明了底层构建的正确性。
体系结构的设计，不仅仅要考虑功能需求，还要考虑非功能需求，要体现对非功能需求的支持。划分网络层就是为了满足异构网络下对可靠性的高要求，通过支持通道绑定和切换，配合数据冗余技术，来满足对高可靠性的要求。而且安全性的需求也要求网络的安全性，因此将这些需求的支持融合到网络层，可以更好的便利业务层的开发。
软件系统的复杂性，涉及技术点的多样性，使得只采用一种风格并不合理也不现实。在层内构件之间和层间的构件之间也有其他风格的应用。比如展示层和业务逻辑层为了更好的实现隔离和内聚，采用了进程通信体系结构风格。还有其他一些风格，在软件架构风格文章中已经进行了详细的描述，这里就不再展开了。
确定风格、确定风格对应的构件，设计出体系结构后，邀请多方代表参与评审，最终明确了体系结构设计。有了高层抽象的概念化的体系结构后，就需要将其文档化，使用语言具体的便于开发和实现人员理解的方式进行形式化约束描述。比如对于前述可靠性要求，在网络构件中就有多环路的设计要求，自动切换的要求，对于前述安全的要求，就有加密的设计，分组分级的设计，业务层构件就有安全规范操作手册相关内容的设计，明确业务流程的合规要求。
在完成文档化工作后，还需要组织一次复审，以检查描述是否全面、完整，表述是否准确严谨，结构层次是否分明清晰。这次复审也是一次查缺补漏的机会，因为关系到后面的实现，也因为邀请了外部领域专家，因此也是一次非常严肃的评审。在评审前，一方面将技术验证的原型进行了汇总展示，另一方面将相关内容分发到参会人员进行准备，收集意见，包括对自己所属领域进行严格审查，对其他模块的依赖和接口要求进行仔细核对，并最终给出初步的意见。这大大提高了会议的效率和深度，取得了很好的效果。起初，专家对多客户端抽象的性能满足与否持有怀疑态度，对数据带宽问题的实现复杂度过于悲观，安全性方面接入限制也持有保留的态度，但在看到原型的展示后，还是高度仍可了大家的分析设计工作。
因为设计阶段的充分工作，评审的严谨，实现阶段大家的积极性很高，没有明显的抵触情绪，彼此的低效沟通减少了很多，很多小节点都得到了保证。许多构件的设计实现工作是比较顺利的。因为完整的单元和集成测试准备工作，系统整体开发进展较为顺利。
软件系统开发的复杂性很多来自需求的变化，这在本项目中更是深刻的体现了出来。在ABSD方法中，体系结构演化就是用来应对需求变化的，整个过程包括提出演化计划，确定更新构件部分，对构件进行变动，包括增删改等更新操作，最后更新构件相互作用并组装进行系统测试。这个过程说起来简单，做起来难上加难。本项目中，一个重大的需求导入就是对卫星通信的支持。由于前期卫星数据通路未开通，采用的是移动网络模拟，但是等到数据开通后，发现之前的设计可行性几乎为零。链路的不可靠带来大量的丢包，协议设计的重传又加重了这一过程，在实际测试中，过低的成功率严重降低了业务的使用信心。这种需求变更最怕的就是产生多米诺骨牌效应，一处修改，被传导蔓延扩散到整个系统，污染了整个设计，这是最不能接受的。为了应对该需求，团队开始时修改了业务的部分流程，并对网络库进行了适应性的修改，在一定程度上缓解了业务失败概率过大的问题，但是并没有彻底解决技术上的限制，业务体验还是难以达到要求。为此，团队对需求的变动进行了二次系统梳理，对相关变更的必要性进行了仔细的校对，对技术实现的约束限制进行了全面仔细的验证测试，在这些信息的基础上，反推到需求层，对需求进行调整，改变了最初过于苛刻的性能要求和体验目标，在大家达成共识的基础上，进行了二次演进处理，并增加了更为全面的测试，收集了系统化的测试数据，为业务的调整提供了更为合理的边界。
在目标修改后，团队的士气得到了明显提升，改进过程得到了快速收敛，最后在增加部分投入时间的情况下，完成了演进过程。通过这次演进，大家都收获很多，也在推动大家主动挑出技术圈子，全局把握系统和业务本质需求上，上了生动一课。
虽然系统设计和实现的整个过程中团队做了大量工作，自认为还是比较充分的，但是实际开发过程中仍然遇到了不少计划外的障碍，包括安全方面的内外网合规要求，开发语言和工具的改变，部署的特殊要求等，这些在内部工作中都没有被很好的预警，额外增加了很多的市场、技术支持和开发工作，这是后续需要改进的。总的来讲，卫星通路的引进属于技术上的重大变更，而这里所述的很多是对业务理解的不够深，对客户环境的理解和掌握不够导致的，因此整体上看，一个项目的成功，不仅仅技术上要做全面的风险设计，非技术方面也要做足风险分析与预案工作，知己知彼百战百胜，在现代竞争激烈的商业环境中，这一道理仍然是十分正确、十分有用的。
