救命！24下软考——系统架构设计师论文范文合集被找到啦！

小伙伴们！24下半年软考考试时间临近，大家应该都已经开始备考了吧！最近听到有很多宝子说被论文难住了，今天小编给大家整理了一份24下软考架构论文范文合集，小伙伴们要多看、多练手，只要掌握住方法，论文也不是那么难跨越的坎！

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

基于架构的软件设计（Architecture-Based Software Design, ABSD）方法以构成软件架构的商业、质量和功能需求等要素来驱动整个软件开发过程。ABSD是一个自顶向下，递归细化的软件开发方法，它以软件系统功能的分解为基础，通过选择架构风格实现质量和商业需求，并强调在架构设计过程中使用软件架构模板。采用ABSD方法，设计活动可以从项目总体功能框架明确后就开始，因此该方法特别适用于开发一些不能预先决定所有需求的软件系统，如软件产品线系统或长生命周期系统等，也可为需求不能在短时间内明确的软件项目提供指导。

请围绕“基于架构的软件开发方法及应用”论题，依次从以下三个方面进行论述。

1. 概要叙述你参与开发的、采用ABSD方法的软件项目以及你在其中所承担的主要工作。

2. 结合项目实际，详细说明采用ABSD方法进行软件开发时，需要经历哪些开发阶段？每个阶段包括哪些主要活动？

3. 阐述你在软件开发的过程中都遇到了哪些实际问题及解决方法。

范例

摘要部分：

**年**月，某集团公司开始了**系统的开发，该系统主要实现**等功能。主要包括**等主要功能模块。我在该系统中担任系统架构师，主要负责该系统的架构设计工作。本文以该系统为例，主要论述了基于架构的软件设计方法在该系统中的具体应用。在架构需求阶段，以构件图、包图、类图和对象图描述系统结构，为系统整体的上层结构进行建模；在架构复审阶段，采用架构权衡分析法来对架构设计方案进行复审，以应对评估质量属性的满足程度问题；在架构演化阶段，采用需求变动管理工具对收集的需求进行归类，以应对需求变动管理问题。经过多轮迭代演化，本系统最终顺利上线，并运行稳定，获得用户一致好评。

【注意：实际写作中相关项目情况应介绍清楚，摘要字数（包括标点符号）一般写到300到320字】

正文部分：

某集团公司**为了应对***，因此**研发**系统。【项目背景内容可分2段写，第1段简要说明下项目来龙去脉】

该项目在**年**月正式启动，旨在通过**，优化**。我在该项目中担任架构师，并负责整体系统的架构设计工作。本系统主要由**等主要模块构成。此外，该系统能**，通过如**得到**。**从而最终实现加强集团公司在银行业的竞争力的目的。【第2段对系统整体情况进行细致介绍，项目背景第1、2段内容可以写到400到450字】

基于架构的软件设计方法，简称ABSD方法，主要包含了架构需求、架构设计、架构文档化、架构复审、架构实现和架构演化六个阶段。其中，架构需求主要包含了需求获取、标识构件、需求评审等活动。架构设计，主要包括提出架构模型、映射构件、分析构件相互作用、产生架构、设计评审等活动。架构文档化，用于把架构设计的成果进行分析与整理并进行文档化。架构复审，用于对架构设计进行复审并标识其中潜在的风险、缺陷和错误。架构实现，包括了架构分析与设计、构件实现、构件组装、系统测试等活动。架构演化，主要活动包括需求变化归类、架构演化计划、构件变动、更新构件的相互作用、构件组装与测试、技术评审等活动。

考虑项目建立初期的需求不稳定，且后续的需要应对大量的新需要，我们决定使用ABSD方法来对系统进行构建与演进。下面将着重描述ABSD方法在本项目应用过程中所遇到的问题和采取的应对方案。

一、架构需求阶段，以构件图、包图、类图和对象图描述系统结构

为了应对架构需求阶段描述系统架构结构的问题，我们在标识构件活动中，使用构件图、类图等来对系统的整体结构进行建模，实现了通过标识构件活动描述架构结构的目的。首先，我们根据获取的需求以类图和包图的形式为系统的下层结构进行建模。若某个构件的业务构成较为复杂，则以对象图进行辅助说明。然后，我们对这些类图和包图进行分组，从而拟定构件的边界。接着，我们安排项目负责人基于上一步得出的类图和包图的分组，并以需求获取活动得到的会议记录和用例图作为辅助，使用构件图设计出需要的构件，再使用这些构件为系统整体的上层结构进行建模。最后，我们使用《需求构件关系表》标识并记录构件与需求之间的关系，用以指导后续的工作。通过这个方案，我们在标识构件活动中，使用构件图、包图、类图等结构更为清晰的视图为系统的整体结构建立了一个更为稳定的基线，从而达到了提升需求到系统设计的转化效率的效果。

二、架构复审阶段，使用ATAM对架构的质量属性进行复审

为了应对对架构设计方案的质量属性满足程度进行评估的问题，我们在架构复审阶段，使用架构权衡分析法（简称ATAM）来对文档化后的设计方案进行复审，从而实现了确定非功能性需求在本系统的架构设计中是否得到满足的效果。首先，考虑到参与ATAM会议的与会人员来自于不同领域的部门，为了便于会议的进行，我们在ATAM的描述和介绍阶段中，为相关人员提供ATAM评估方法、系统业务动机和架构整体设计作为知识基础。然后，我们在ATAM的调查和分析阶段中，使用基于质量属性的评估方法（如建立质量效用树等），对评估系统架构满足非功能需求的情况进行评估。接着，我们在ATAM的测试阶段中，基于场景的验证方案来对上一步评估结果进行验证，从而通过质量场景和场景的优先级对架构方案进行调整。通过这个方案，我们在架构复审阶段中，使用ATAM来为架构设计方案的质量属性进行评估，从而确定非功能需求在架构设计中的满足程度并通过质量场景调整架构方案的目的。

三、架构演化阶段，对需求变化进行归类

为了应对架构演化阶段的需求变动管理问题，我们在需求变化归类活动中，使用数个工具对收集的需求变动进行整理与分类，实现了对需求变动与构件之间的关系进行管理的目的。首先，我们把新的需求变动登记到《需求管理列表》中，并通过该表获得新的需求变动与旧需求的对应关系。而当某个新的需求变动和旧需求建立起关系时，我们可以通过上次迭代生成的《需求构件关系表》和《开发工作登记表》，推导出新需求变动与系统已有构件及这些构件的开发人员的对应关系。然后，把新需求与系统中已有构件和候选处理人员的对应关系回填到《需求功能关系表》中。而当某个新需求的需求点和旧需求无法建立起关系时，我们直接把新需求写到《需求构件关系表》中并标记为新增。然后我们再通过召开相关干系人的会议，议定每个变动的实现优先级和跟进人员。通过这个方案，我们不但达到了对需求变动与构件之间的关系进行管理的目的，还能划定较适合处理这些需求变动的候选人名单以指导后续工作之用。

由于使用了以上ABSD方法来对项目进行开发与演进，该系统改进工作十分顺利，经过多轮迭代演化，本系统最终于**年**月顺利上线，并运行稳定，用户普遍反馈功能可以满足工作需要且使用体验良好。实践证明ABSD方法适用于该项目的变动管理。

然而，我们在应用ABSD方法的过程中还存在着一些不足，如我们发现因人手更替，导致一些构件的跟进人员产生变动，这将会产生额外的学习成本。因此，我们决定在后续的演化中，每个构件都需要维护一份更详尽易懂的文档，并在技术评审阶段对本轮迭代中的这些文档进行审核来缓解这个问题。通过本次项目，我认识到紧贴业务需求、数据和开发小组的构成情况来选择具体的软件设计方法将会大大地影响一个项目的演进能力。而在选定软件设计方法后并不意味着结束，通过对方法的细节进行不断改进，将是项目成功的关键。

论软件系统架构风格

系统架构风格（System Architecture Style）是描述某一特定应用领域中系统组织方式的惯用模式。架构风格定义了一个词汇表和一组约束，词汇表中包含一些构件和连接件类型，而这组约束指出系统是如何将这些构件和连接件组合起来的。软件系统架构风格反映了领域中众多软件系统所共有的结构和语义特性，并指导如何将各个模块和子系统有效地组织成一个完整的系统。软件系统架构风格的共有部分可以使得不同系统共享同一个实现代码，系统能够按照常用的、规范化的方式来组织，便于不同设计者很容易地理解系统架构。

请以“软件系统架构风格”论题，依次从以下三个方面进行论述：

1．概要叙述你参与分析和开发的软件系统开发项目以及你所担任的主要工作。

2．分析软件系统开发中常用的软件系统架构风格有哪些？详细阐述每种风格的具体含义。

3．详细说明在你所参与的软件系统开发项目中，采用了哪种软件系统架构风格，具体实施效果如何。

范例

摘要部分：

本人于**年**月参与**项目，该系统为***，在该项目组中我担任系统架构师岗位，主要负责系统整体架构设计。本文以该车联网项目为例，主要讨论了软件架构风格在该项目中的具体应用。底层架构风格我们采用了虚拟机风格中的解释器，因该公交共有几十种不同的数据协议，使用解释器风格可以满足整车数据协议兼容性需求；中间层关于应用层的数据流转采用了独立构件风格中的隐式调用，以减低系统间耦合度、简化软件架构，提高可修改性方面的架构属性；应用系统层采用了B/S的架构风格，统一解决公交行业性难题“实施推广难、维护难”问题。最终项目成功上线，获得用户一致好评。

【注意：实际写作中相关项目情况应介绍清楚，摘要字数（包括标点符号）一般写到300到320字】

正文部分：

随着**，**集团自**年**月起****，规划***。【项目背景内容可分2段写，第1段简要说明下项目来龙去脉】

**年**月我司**委托建设***项目。本项目****，我在项目中担任系统架构师职务，主要负责系统整体架构设计，该系统主要***，主要功能模块包括**。【第2段对系统整体情况进行细致介绍，项目背景第1、2段内容可以写到400到450字】

在架构工作开始阶段，我们便意识到，架构风格是一组设计原则，是能够提供抽象框架模式，可以为我们的项目提供通用解决方案的，这种能够极大提高软件设计的重用的方法加快我们的建设进程，因此在我司总工程师的建议下，我们使用了虚拟机风格、独立构件风格以及B/S架构风格这三种较常用风格。虚拟机风格中的解释器架构风格能够提供灵活的解析引擎，这类风格非常适用于复杂流程的处理。独立构件风格包括进程通讯风格与隐式调用风格，我们为了简化架构复杂度采用了隐式调用风格，通过消息订阅和发布控制系统间信息交互，不仅能减低系统耦合度，而且还提高架构的可修改性。B/S架构风格是基于浏览器和服务器的软件架构，它主要使用http协议进行通信和交互，简化客户端的工作，最终减低了系统推广和维护的难度，以下正文将重点描述架构风格的实施过程和效果。

底层架构我们使用解释器风格来满足整车数据协议兼容性需求。解释器风格是虚拟机风格中的一种，具备良好的灵活性，在本项目中我们的架构设计需要兼容好86种不同can数据协议，一般来说这种软件编写难度非常高，代码维护难度压力也很大，因此这个解释器的设计任务便很明确了，软件设计需要高度抽象、协议的适配由配置文件来承担。具体的做法如下，我们对各个车厂的can数据结构进行了高度抽象，由于can数据由很多数据帧组成，每个数据帧容量固定并且标识和数据有明确规定，因此我们将can协议中的ID和数据进行关系建模，将整体协议标识作为一个根节点，以canid作为根节点下的叶子节点，使用XML的数据结构映射成了有整车协议链-数据帧-数据字节-数据位这4层的数据结构，核心的代码采用jdom.jar与java的反射机制动态生成java对象，搭建一套可以基于可变模板的解释器，协议模板的产生可以由公交公司提供的excel协议文档进行转换得到，解释器支持协议模板热部署，这种可以将透传二进制数据直接映射成java的可序列化对象，将数据协议的复杂度简化，后期数据协议更改不会对软件产生影响，仅仅更改协议模板文件即可，最终我们使用了86个协议描述文件便兼容了这些复杂的can数据协议，规避了can数据巨大差异带来的技术风险。

中间层我们使用独立构件风格中的隐式调用来简化构件间的交互复杂度，降低系统耦合度。主要的实现手段是，我们采用了一个开源的消息中间件作为连接构件，这个构件是apache基金会下的核心开源项目activemq，它是一款消息服务器，其性能和稳定性久经考验。由上文提到的解释器解析出对象化数据经过activemq分发到各个订阅此消息的应用系统，这些应用系统包括运营指挥调度、自动化机护、新能源电池安全监控等，这种多web应用的情况非常适合采用消息发布与消息订阅的机制，能够有效解决耦合问题，我们在编码的过程中发现只要采用这种风格的web应用，整个迭代过程效率极高，错误率降低，而且我们使用的spring框架，消息队列的管理完全基于配置，清晰简单，维护性良好，例如整车安全主题、运营调度主题、机护维修主题等消息队列分类清晰，可以随时修改其结构也能够随时增其他主题的消息队列，不同的web系统监听的队列也可以随时变换组合，基于消息中间件的架构设计能够让系统的构件化思路得到良好实施，总体来说这种架构风格带来了非常清晰的数据流转架构，简化了编码难度，减低本项目的二次开发的难度。

应用系统层我们主要采用B/S的架构风格，主要用于解决公交推广难、维护难的问题。公交行业有一个明显的特点，公交子公司分布在全市各个地区，路途很远，且都是内网通讯，车联网络也是走的APN专网，一般是无法远程支持的，这给我们的系统推广以及后期维护带来了很大难题，我们可以想象如果使用C/S架构，更新客户端一旦遇到问题很可能需要全市各个站点跑一遍。这让我们在系统推广和维护方面面临较大压力。我们采用的B/S架构风格能够解决这个难题，并充分考量了现在相关技术的成熟度，例如现在的html5完全能够实现以前客户端的功能，项目中我们使用了大量的前端缓存技术与websocket技术，能够满足公交用户实时性交互等需求。这种风格中页面和逻辑处理存储在web服务器上，维护和软件升级只要更新服务器端即可，及时生效，用户体验较好，例如界面上需要优化，改一下Javascript脚本或者CSS文件就可以马上看到效果了。

项目于**年**月完成验收，这 1年内共经历了2次大批量新购公交车辆接入，这几次接入过程平稳顺利，其中协议解释器软件性能没有出现过问题，消息中间件的性能经过多次调优吞吐量也接近了硬盘IO极限，满足当前的消息交互总量，另外由于我们的项目多次在紧急状态下能够快速适应can协议变动，得到过业主的邮件表扬。除了业主机房几次突发性的网络故障外，项目至今还未有重大的生产事故，项目组现在留1个开发人员和1个售后在维护，系统的维护量是可控的，系统运行也比较稳定。

不足之处有两个方面，第一在架构设计的过程中我们忽略PC配置，个别PC因为需要兼容老的应用软件不允许系统升级，这些电脑系统老旧，其浏览器不支持html5，导致了系统推广障碍。第二在系统容灾方面还有待改善。针对第一种问题，我们通过技术研讨会说服业主新购PC，采用两台机器同时使用方式解决。针对第二种问题我方采用了服务器冗余和心跳监测等策略，在一台服务暂停的情况下，另外一台服务接管，以增加可用性。

......

篇幅有限，有需要PDF完整版或更多资料的朋友，可以自行获取↓↓↓

论文备考策略：

1、早早的学好写作技巧

写作技巧包括论文框架如何搭建，摘要写作要注意什么，项目背景如何介绍，怎么过渡，主体内容写作要注意什么，怎么结尾等。

表达能力也很重要，文章过于口语化、错别字很多、文理不通顺也是会扣分的。

2、早早的选好项目

项目简介、项目背景等相关内容，是无论什么论文主题都适用的，可以自己写了修改完善后再背下来，考试时可以节省很多时间。

在选择项目时，尽量选择自己实际做过、实际参与过、实际做过其中一部分或者自己用过的项目，这样写出来的论文会更真实可信，注意不要选择年代久远的项目。

3、学以致用

在学习各项技术时，就要有意识的想这项技术能不能用在我的项目中，如何用。

4、论文要准备的是素材

素材是组织成文的构件，构件全了，什么都不是问题。

5、打字速度慢的同学，可以提前练习打字。

写作字数上不能过少也不能偏多。如要求写摘要，摘要不超过300字，正文不少于2000字，但不能超过2500字，建议控制在2250-2500字是最好的。