论基于架构的软件设计方法及应用

论基于架构的软件设计方法及应用
摘要：2020年4月，本人所在的某市金融投资集团启动了集团综合管理系统建设，该项目实现基金、融资租赁、资金管理、转贷、融资担保、保理等金融业务信息化及人力资源、智能办公、法务管理等内部管理功能。在此项目中，我担任了架构师，负责项目总体架构设计工作。本文以该综合管理系统为例，主要论述了基于架构的软件设计方法及应用。在架构需求阶段，以系统的商业需求及质量需求出发标识系统构件，如通用业务构件及特定业务构件，并进行需求评审；在架构设计，将业务构件映射到层次架构风格中并分析相互作用，产生系统架构，并进行设计评审；在架构复审，通过SAAM技术分析架构对于不同质量场景的满足情况，综合比选，选出最合适系统开发的方案。最终项目顺利上线，运行平稳，获得了领导的高度认同。
正文：本人所在的某市金融投资集团已经建设了移动办公系统、财务系统、融资租赁系统、基金管理系统等应用系统，但仍有部分业务缺乏信息化支撑，已建成的系统比较分散，主要是“竖井式”方式建设，系统与系统之间信息不共享以及信息与业务流程相脱节。针对这些问题，2020年4月，经集团党委决定，启动集团综合管理系统建设，实现以下功能。一、实现转贷、保理、融资担保、资金管理、人力资源、智能办公等业务流程信息化，同时整合基金管理系统、移动办公系统、财务系统等已有信息资产，促进部门、子公司之间横向协同。二、建立统一共享的信息平台，利用数据报表平台为管理层提供决策信息支持，实现纵向管控。三、建立涵盖分布式文件存储、单点登录、分布式事务支持、短信邮件通知、可控任务调度等服务的基础IT设施，提供高质量、可重用的平台服务。
在此项目中，我担任架构师一职，负责系统总体架构设计。为减少体系结构不确定性带来的技术风险，并提升应用的可复用性，为后续新业务扩展提供可快速扩展的体系结构，本系统采用基于架构的软件设计方法。
在基于架构的软件设计方法中，开发阶段包括架构需求、架构设计、架构文档化、架构复审、架构实现、架构演化6个阶段。架构需求阶段有1.需求获取，包括系统的商业需求、系统的质量需求及系统开发人员的商业需求；2.标识构件，包括生成类图，将类分组，将类打包成构件3个步骤；3.需求评审。架构设计阶段有提出架构模型，最主要的就是明确架构风格，然后映射构件，分析构件之间的相互作用，产生软件架构，最后开展技术评审。架构文档化的两个主要产出是架构规格说明书及测试架构的质量设计说明书。架构复审是通过评审找出系统架构设计存在的风险点及缺陷、错误，是否满足用户需求，构件划分是否合理等。架构实现包括设计与分析、构件实现、构件组装、构件测试。架构演化包括对演化需求进行归类、制定演化计划、构件变动、更新构件间的相互作用、构件组装及测试、架构评审。
本文主要从架构需求、架构设计、架构复审三个阶段对基于架构的软件设计方法及应用进行阐述。
一、架构需求。
为全面支持集团信息化工作，集团成立信息化专班。在这个基础上，我们可以让各业务领域专家抽出足够的时间与我们进行沟通交流，包括会议形式、简单谈话形式、邮件形式等，我们对交谈内容进行记录，并汇总设计形成界面原型，另外不单单是功能性的需求，我们也详细了解了系统需要面对的质量场景，包括性能、可用性、安全性及可修改性的要求。最终，我们形成了包括租赁、基金、资管、转贷等各金融业务以及人力资源、财务、法务等后台职能部门需求。在此基础上，我们进行设计产生类图，以各金融业务为例，包括项目、尽调、客户、方案、合同、投放、收付款、收尾等类别，然后根据业务不同，我们将其划分为不同组别，即基金为一组、租赁为一组等，在此基础上形成了基金构件、租赁构件等具体业务构件。经过分析，我们发现各金融业务都有相同的流程和实体，如都有项目、合同、投放、收付款等实体，并且都是项目立项、尽调、合同签订等通用流程，因此我们在此基础上设计了通用业务构件，而其他业务构件在此基础上进行扩展定制。在需求评审阶段，业务部门对该设计给予一致肯定，并对需求进行确认。
二、架构设计。
首先，以以往的经验以及各开发人员对于框架的熟悉程度，我们选择了层次架构风格作为架构模型的基础，分为表现层、业务逻辑层、数据访问层。下面以通用业务构件及具体业务构件为例进行阐述。根据所选层次架构风格，同样，我们将通用业务构件分为前端组件、控制器、界面实体、传输实体、服务、数据访问对象即DAO，从而实现项目立项、项目尽调、合同签订等功能。通过分析，具体业务构件应在通用业务构件基础上进行开发，即具体业务构件应充分发挥通用业务构件的通用性，最大化利用通用业务实体及业务逻辑，具体业务构件应只包含自身定制化的数据及流程，而不应该重复实现。因此通用业务实体所提供的的接口应充分考虑到这一点，两个构件之间会存在大量的接口使用和继承。另外，我们还设计了一系列用于支持业务构件的基础构件，包括登录鉴权构件，访问控制构件，分布式存储构件等，这部分构件的独立实现，良好设计的接口帮助了业务组件快速实现，并且安全稳定。然后分析后我们产生了软件架构。在评审时，大家也对这种设计方式表示肯定。
三、架构复审。
在产生架构规格说明书及质量设计规格说明书后，我们需要对设计进行复审，经过选择我们采用SAAM基于场景的架构评审技术进行评审。首先我们组织了评审小组，由各业务部门专家、系统分析师、系统设计师、系统实现人员参加，将需求阶段以及后续阶段收集到的场景全部列出来，形成包含已知场景的场景列表，然后在会议上，根据各个场景的重要性确定其在总分中的占比，也就是说并不是每个场景都是一样的比重。由我为大家对列表中的场景评估现行架构情况，分析架构对于这些场景的满足情况，再分析场景交互情况，最后综合比对多个方案对于场景的。比如为了保证数据的完整性与一致性，对于客户经理提交的数据，必须有复核人进行复核后才能进行下一步，这样虽然牺牲了系统的便利性，但是提高了系统的数据正确性。有比如为确保数据不丢失，数据库采用异地主从复制机制，这样一定程度加大了数据库主系统的负担，降低了性能，但是能大大提高数据的安全性。通过这样复合的评审机制，大家对于各个架构设计对于每个场景进行评分，然后综合选取总分最高的架构。
当然，在开发过程中我们也遇到各种问题。如由于通用业务构件与具体业务构建之间存在极强的耦合性，并且复用也是基于白盒，因此存在通用业务构件修改可能会导致原本能够正常使用的构件出现异常。为避免这样的问题，我们确定了若干保障机制，编写详细的通用业务构件使用文档，确保开发人员对其有足够的了解，编写足够多的单元测试，当通用业务构件修改时，必须确保所有业务构件的单元测试通过，另外对通用业务构件修改必须进行回归测试，必要时，开展业务专家、架构设计师、需求分析师等各方人员参加的评审会议。
2021年9月，综合管理系统顺利上线，运行平稳，获得了领导和同事的一致好评。由于采用了基于架构的软件设计方法，项目相关人员从初始就形成了对架构的初始概念，大大降低了技术风险，并且由于设计合理，也使得项目完成时间远远快于预期。