基于模型的敏捷软件架构设计方法

文/蒋丹 刘永吉

1 引言

敏捷开发是一种以用户的需求进化为核心，采用迭代、循序渐进的方法进行软件开发的方法。近年来，敏捷开发方法运用越来越普遍，许多公司（如IBM、Google等）纷纷采用了敏捷开发方法。Ansgar等阐明，敏捷开发方法以其精益开发、简单可靠、增量快速交付等特征，得到了软件业界的广泛关注。同时，在全球大背景下，IT行业软件开发中由于子系统数量不断增长、功能模块增长、逻辑任务增长、子系统耦合度提高等问题，导致软件开发需要高可读性和高可复用性，必然需要软件向基于模型的敏捷架构靠拢。

本文根据敏捷开发理论，研究面向模型的敏捷架构设计方法。从架构设计方法的角度，首先，分析了传统软件架构开发中的弊端；其次，分析了基于模型的软件架构技术；最后，将敏捷开发与基于模型的软件架构方法结合，提出了一种基于模型的敏捷架构设计方法。

表1：基于文档的软件工程与基于模型的软件工程设计元素对比

2 传统的软件架构

传统的软件开发一般采用瀑布模型，瀑布模型将开发和交付企业软件项目的流程分割为相互独立的阶段，每个阶段都要完成规定的文档。架构设计方面，瀑布模型的支持者主张大设计前置（BDUF），这也是众多计划驱动软件开发方法论的普遍做法。如图1所示。

由于，传统的软件架构设计是根据所有的需求文档设计出的大型架构，使得其传统系统分析与设计方法都不能很好地适应不断变化的环境。虽然传统软件开发方法已经被软件界人士所认可，但这也无法掩盖传统软件开发方法存在的问题和弊端，比如，不能保证软件质量，软件开发周期长，软件可靠性、可扩展性和可重用性不能良好体现等。同时，传统的软件开发也是一种基于文档的开发。通过产生的需求文档、设计说明文档等，进行代码的编写，这种基于文档的开发，不仅会照成工作量大、人力资源无法保证文档的维护，而且手工编码引入了人为错误，开发效率低下，设计与现实脱节，无法保证文档与代码的一致性，最重要的是，基于文档的传统开发中的需求无法进行仿真验证，错误只能放在后期发现，代价极大。最重要的是，容易造成架构的浪费以及不可变。

图1：软件开发中软件架构的一般过程

3 基于模型技术

基于模型的技术是采用面向对象的设计方法，基于系统建模语言SYSML的建模机制对系统的行为和架构进行设计与分析，与软件工程思想一脉相承。见表1。

如图2所示，基于模型的软件开发结构的核心是基于抽象。通过规范化的建模语言和方法消除传统方法的缺陷。开发人员可以通过建模语言和方法掌握进行模型的建立、并对模型进行验证。基于模型不等同于基于图形或者基于工具，它是方法论和思维方式的升华，要行之有效的全面推行，就要使得广大设计人员正确认识它。从时间占比上，基于模型的开发方法在前期会占用大量的时间，因此，需要整个研制体系、上下游都理解并适应这种方法带来的影响和改变。

4 敏捷软件架构设计方法

4.1 敏捷开发

敏捷软件开发是一种从1990年代开始逐渐引起广泛关注的一种新型的以人为核心、迭代、循序渐进的开发方法，它的核心思想在于快速、增量式的交付可工作的软件。在敏捷软件开发中，软件项目被分解成多个子项目，各个子项目的成果都经过测试，具备可视、可集成和可运行可使用的特征，经多次迭代来完成，每次迭代都有明确的目标并能快速交付可运行的软件。

如图3所示，敏捷开发与传统软件开发的不同之处在于，传统的软件开发需要将所有的软件需求进行整合，对所有需求统一进行需求分析，软件设计，代码编写和测设；而敏捷开发的特点在于对当前需求进行需求分析，软件设计，代码编写和测试，按此步骤依次迭代每个需求，直到所有需求均被迭代完毕。

图2：基于模型的软件工程

4.2 敏捷软件架构

图3：传统开发与敏捷开发过程差异

图4：敏捷开发前和敏捷开发后的架构设计方法

在传统软件开发中，需求分析阶段规划好大量的功能需求和非功能需求，架构师针对这些需求进行整合后进行架构设计。架构设计是同时完成分析和设计两项工作。而在敏捷开发中，需求是迭代式进行收集，每次迭代进行设计时，仅仅对当前的需求进行建模，会随着每次迭代的进行，逐步调整架构设计。所以，可以看出传统软件架构和敏捷方法之间的紧张关系（沿着最后可能的时刻留下架构决策）与预期（提前规划）之间的紧张关系。

同时沃特曼，诺贝尔和艾伦探讨了在设计前期架构时花费太少时间，增加风险和花费太多时间，对客户价值交付产生负面影响之间的紧张关系。他们确定了可能影响敏捷架构的六种力量：需求不稳定性，技术风险，早期价值，团队文化，客户敏捷性和经验。这些力量可以通过六种策略来解决：响应变化，解决风险，新兴架构，预先设计大型设计以及使用框架和模板架构。敏捷架构原则通过协作，紧急设计，有意架构，设计简单性以及可测试性，可部署性和可释放性设计来支持精益敏捷开发。快速原型设计，领域建模和分散式创新进一步支持了它。软件架构设计描述的是事物本身，而敏捷开发描述的是创建这个事物的过程；敏捷开发中架构设计的方式，指什么时候进行架构设计，并以什么样的方式进行架构设计。

图4中，敏捷开发后软件架构设计的方式产生了变化；敏捷开发把原先软件过程前期的架构设计，分散到了整个敏捷开发软件过程中。

看到敏捷开发中分散化的架构设计，想起公司财务中的“马克威茨资产组合理论”，用马克威茨资这个诺贝尔大师的理论来解释敏捷开发中的分散架构形式，也行得通。“马克威茨资资产组合理论”中说道：可以通过分散投资使收益率不变而方差（风险）减少。通俗一点讲也就是不要把鸡蛋放在一个篮子里。

如果按照资产组合理论，下面这些就是软件架构设计中的组合，把一次性软件过程前期30%（甚至更多）的架构设计，换成如下的软件组合：

（1）引入新需求后的架构。每次迭代中，新需求引入前，都可以进行构思和架构；

（2）重构产生架构。先让软件运行，再重构其代码。那么软件的架构随着重构自然而然的在软件过程中产生；

（3）开发过程中的设计：以前是设计完后开发，现在是边设计边开发；

（4）所以敏捷开发不是轻架构设计，而是依然注重架构设计。只不过架构的方式变化了，变得更加有效且风险更小。

图5：敏捷开发中迭代式架构设计过程

4.3 基于模型的敏捷架构设计

在数字化转型的大趋势下，基于模型是走向设计的技术保证，而选择敏捷结构设计方法是追求速度与质量平衡。在基于模型的开发工程中，传递的是模型而不再是文档，基于模型在软件实现前可以而且应该更好地与客户沟通、确认需求。同时，大量的模型验证工作在软件实现前可以而且应该得以展开。

重构是敏捷开发的重要技术，就是在不改变软件现有功能的基础上，通过调整程序代码改善软件的质量、性能，使其程序的设计模式和架构更趋合理，提高软件的扩展性和维护性。本文将利用重构技术来进行架构设计，如图5所示描述了敏捷开发中迭代式架构设计过程。敏捷开发中进行架构设计的核心思想是进化式设计。进化式的设计是指在敏捷开发的整个生命周期中，通过每一次迭代来充实、修改和优化设计方案，以使其最大限度地符合客户对系统的需求。它是不伤害到现有架构的能力和已经实现的功能，同时对其他部分的影响尽可能小。

在基于模型的敏捷架构设计中，每一次迭代的架构设计过程大概分为八个步骤：

（1）需求分析阶段，通过周期性收集用户的业务需求，使用Doors工具进行软件需求分析与管理，生成软件高层需求文档，形成Product Backlog列表；

（2）在Visual Studio2010（或其他工具）中，将Product Backlog列表分解成一个个用户故事（对单一功能实现的描述），用户故事有三个参照值：Stack Rank（优先级）、Story Point（实现难度、工作量）、Risk（风险）；

（3）团队一起将每一个用户故事进行细化成一个个Task。团队成员领取Task进行开发；

（4）在整个项目开发生命周期内，需要对需求订单进行不断维护，同时也要对需求变更进行管理与跟踪。

（5）采用SCADE Suite、SCADE Display进行软件设计，开发软件低层需求，建立高层需求与低层需求的追踪关系；

（6）根据需求模型，软件详细设计阶段采用SCADE Suite、SCADE Display进行软件控制逻辑和人机交互设计，并通过需求追踪管理工具建立模型与需求之间的追踪关系。形成当前迭代的Architecture Backlog，确定项目系统中某模块的架构样式，明确每层需要的技术；

（7）每次迭代根据Architecture Backlog实现的功能，通过使用IBM rational rhapsody工具画时序图等；

团队开发成员、架构师、产品负责人以及测试组相关成员参加架构设计评审，评审通过后进入开发阶段，以正确的起到指引、框定的作用，使得开发朝着正确的方向进行。

5 结论

基于模型的敏捷架构是一种精益敏捷方法，可以解决构建企业解决方案的复杂性。反过来，基于模型的敏捷架构设计方法支持当前用户的需求，同时改进系统以满足近期的未来需求。这种方法允许系统架构（甚至是大型解决方案）随着时间的推移而发展，同时支持当前用户的需求。 这避免了与启动 - 停止 - 启动性质相关的开销和固有的重新设计。借助敏捷架构，系统始终运行，支持更持续的价值流。同时，能够避免系统过载，该模型构成经济框架的一部分并帮助分散决策，这两者对于快速，可持续的价值流动至关重要。

对于传统开发中不能很好的适应不断变化的环境，架构的可扩展性和可重用性不良好，以及随着应用程序的扩展和时间的推移，内核的体量往往会开始成为沉重负担，本文提出了一种基于模型的敏捷架构设计方法，该方法不仅开发节约了时间成本，并且提了软件产品质量。在未来的相关研究中，我们会将面向模型的敏捷架构等方面推广到更大的项目中，并进一步完善该方法。