论基于架构的软件设计方法（ABSD）及应用
2025年3月22日作
题目
基于架构的软件设计（Architecture-Based Software Design, ABSD）方法以构成软件架构的商业、质量和功能需求等要素来驱动整个软件开发过程。ABSD是一个自顶向下，递归细化的软件开发方法，它以软件系统功能的分解为基础，通过选择架构风格实现质量和商业需求，并强调在架构设计过程中使用软件架构模板。采用ABSD方法，设计活动可以从项目总体功能框架明确后就开始，因此该方法特别适用于开发一些不能预先决定所有需求的软件系统，如软件产品线系统或长生命周期系统等，也可为需求不能在短时间内明确的软件项目提供指导。
请围绕“基于架构的软件开发方法及应用”论题，依次从以下三个方面进行论述。① 概要叙述你参与开发的、采用ABSD方法的软件项目以及你在其中所承担的主要工作。
② 结合项目实际，详细说明采用ABSD方法进行软件开发时，需要经历哪些开发阶段？每个阶段包括哪些主要活动？
③ 阐述你在软件开发的过程中都遇到了哪些实际问题及解决方法。
摘要
我司自主研发的某省预约挂号系统以后简称预约挂号系统，该系统集众多功能与一体，旨为提高医疗服务质量和患者体验。随着用户量的逐年增加系统面临的性能瓶颈和可用性的严峻挑战，严重阻碍了系统服务质量进一步提升。我担任公司的系统架构设计师，主要工作是对系统架构的整体设计。面对系统的两大问题，我们采用了基于架构的软件设计方法，其有架构驱动设计、递归细化的特点，让我门在面对预约挂号的整体业务时有了切入点，我们又通过体系结构的需求、设计、文档化、复审、实现和演化的阶段，完美完成了系统的升级工作，为后期的千万级的用户量奠定基础，更是顶住了名医抢号功能的高并发访问，轻松应对万级的用户请求，得到了领导和组员的高度认可。
背景
随着信息化时代的到来，各大医院纷纷拥抱线上系统。我司顺应时代的潮流自主研发了一套功能全面的预约挂号系统，系统集预约挂号、体检预约、报告查询和名医抢号等核心功能于一体，旨为提高医疗服务质量和患者体验。但随着用户基数的逐年增长，系统面临着性能瓶颈和可用性的挑战，严重阻碍了系统服务质量的进一步提高。为了保证系统能够持续稳定的运行，我司于2023年3月毅然决定对系统进行全面升级和新功能的开发工作，计划一年时间，投资800万，我担任系统架构设计师，主要工作涵盖了系统架构的整体设计、技术栈精准选型和每个核心阶段的评审工作。根据系统需求和讨论，我们选择了基于架构的软件设计方法，通过对业务的分析细化，得出构件组装成系统架构。根据架构驱动设计，通过了体系结构的需求、设计、文档化、复审、实现和演化等阶段，经过一年的不懈努力，成功如期圆满完成，我们挺住了千万级的用户量，并在名医抢号功能的高并发环节，轻松应对万级的请求量，项目组成员和领导给予了高度认可。
理论
由于预约挂号系统涉及业务量巨大，各个系统的技术含量和价值又高低不同，比较难以划分，而基于架构的软件开发方法正好有通过架构来驱动系统的设计，完美的指导了预约挂号系统的设计，接下来我描述一下基于架构的软件设计方法主要经历的阶段，以及每个阶段的具体活动。
基于架构的软件设计方法是一个架构驱动设计、用例标识系统的功能需求、视图视角标识系统的架构、质量场景标识质量需求。还有指导自顶向下递归细化的特点。该方法需要经历六个阶段：
一、体系结构需求阶段。1.需要从需求库或用户等处获取需求，使用用例图表示。2.根据用例图生成类图，然后对类进行分组，最后把类打包成构件。3.邀请项目组成员对构件评审。
二、体系结构设计阶段。1.提出复合系统的架构模型。2.获取构件。3.设计构件间的相互作用。4.分析出体系结构模型。5.阶段评审。
三、体系结构文档化。1.根据整理出来的设计材料，编写体系结构规格说明书、测试体系结构的说明书。
四、体系结构复审。1.组织项目干系人、外部的用户和领域人员等，对系统的设计进行全面的评审，主要任务是分析出系统的风险因素和设计的缺陷，阶段迭代进行。2.得到最终的体系结构设计文档。
五、体系结构实现。1.根据体系结构设计文档选择构件。2.按照构件的关系图，组装部署构件成系统。3.对系统进行测试。4.发现问题，然后阶段迭代，直至完成最终系统。
六、体系结构演化。1.收集变更需求，并分类。2.编写变更计划。3.增删改构件，并更新体系结构的关联关系。4.对系统测试。5.演化后的体系结构。
实践
预约挂号系统基于架构的软件设计方法实施有六个阶段，其中遇到的问题以及解决方法如下：
一、体系结构需求阶段。1.首先我从需求库中整理了老系统的需求，又进行问卷调查、与领导探讨整理了预约挂号的需求，发现业务需求都融合在一起，杂乱无章。我通过分析把业务类总体分成医院、患者、订单、支付和三方对接服务，得到了用例图。2.我根据用例图：a.把医院、科室和医生归类为机构类；b.患者和用户归类为用户类；c.预约挂号、体检预约和抢号产生的订单信息等归类为订单类；d.患者的所有支付操作归类为支付类；e.与三方医院的对接归类为三方服务类；f.最后把类打包成构件，即机构服务、用户服务、订单服务、支付服务和三方服务等。3.组织项目干系人、领域专家和领导进行评审，发现在各类中有很多公共类，比如机构服务中查询地区编号，用户、订单等服务中也会查询，没有必要编写多套，经过讨论在原来的类别中增加公共服务构件，用来处理所有应用的公共操作部分。
二、体系结构设计阶段。1.我根据需求分析得到的用例图和获得的构件进行分析，提出了独立构件和调用返回等架构风格。2.我组织了一场通过质量场景的架构评估方法，经过对构件和系统质量需求的分析发现：a.预约挂号系统的构件众多，相互调用没有明确的操作顺序很容易产生循环调用的风险，为了系统的可用性，我决定牺牲部分性能，对现有构件进行下沉设计形成基础构件，上层增加聚合器服务用来聚合处理基础构件提供的数据，而基础构件之间隔离。b.而在性能方面为面对即将突破千万的用户量，我决定应用层采用负载均衡、多副本部署构件。数据层采用分布式代理、分布式部署和缓存的策略来部署构件。3.经过多轮的评审讨论，我们决定采用层次式架构风格，并使用分布式、微服务部署策略。
三、体系结构文档化。1.根据具体的架构风格，我通过活动图、序列图和通信图描述系统的行为。通过状态图描述对象的生命周期内状态间转换的条件和事件，例如：患者产生的订单从预约到就诊的一系列状态转换。最后形成体系结构规格说明书，指导实现阶段工作。2.我与测试人员共同编写了测试体系结构的说明书，方便后续的测试工作。
四、体系结构复审。1.我邀请了外部医院、用户和领域人员等代表，还有项目组内干系人，一起评审了体系结构的设计文档。经过讨论感觉预约挂号系统的可用性还未达标，我又提出了同城主备、异地主备的两种方案，经讨论异地主备两地系统通信实现成本较高，决定采用同城主备的方案。2.经过多轮评审和文档改造，得到了最终的体系结构规格说明书和测试体系结构说明书等文档。
五、体系结构实现和演化。1.根据最终的设计文档，我们从构件库中获取到了支付服务、三方服务和公共服务等构件，还有机构服务、订单服务、用户服务构件没有，需要新开发，不过可以通过机会复用从老系统中拆分代码到构件中。2.根据体系结构规格说明书部署获得的构件。3.根据测试体系结构说明书，按步骤测试预约挂号系统。4.预约挂号系统上线运行和运维。5.最后进入演化阶段，收集用户评价、变更的需求、对需求进行优先级排序和分类，根据变更增删改构件，更新设计文档，测试上线，得到演化后的体系结构。
结尾
预约挂号系统使用了基于体系结构的软件设计方法效果不错，经过一年的不懈努力最终成功实施，2024年3月初正式上线，经过一个月的精心推广，又吸引了大批的用户，现已突破千万大关，系统平稳运行，特别是应对名医抢号功能的并发处理能力，轻松应对万级的用户请求，显著提升了系统的性能和可用性，赢得了项目组成员和领导的高度认可。然而在开发初期，有项目组成员对开发模型的理解模糊不清，一度阻碍了项目进度的推进，针对这一问题我们迅速行动，通过项目组间人员的灵活调配，完美解决了这一短板。接下来我们准备迁移老数据库的数据到新库，经过此次实施，我们对迁移方案充满信息，将以更高的要求和标准完成任务。对于我而言，此次架构的设计是一个不可多得的机会，我的技术和经验得到了显著的提升。