一 系统架构设计师论文

写论文有一些套路，可以参考文章：https://mafgwo.cn/2022/06/16/1216_jiagoulunwentaolu/
此篇文章中的三篇论文，都是按上面的套路写的三篇文章，是经过某培训机构老师审阅过且经过多番修改后能达到及格线的文章。
可以从这三篇论文，掌握一个项目背景如何运用到多个主题当中的技巧。
特别提醒： 论文仅供参考，别直接用于应试，尽量用自己的项目背景，就是杜撰的也比用本文的项目背景好（公开于网上的项目背景都不要直接使用）。

二 论文一：论基于架构的评估方法

摘要：
        2020年3月，本人所在的公司为集团下属某能源公司开发了一套工业互联网系统。该系统主要负责采集工业设备的遥测、遥信数据，再经大数据做实时或离线计算等分析，以达到工业设备智能运维的目的。我在项目中主要担任架构师角色，主要负责系统架构设计相关的工作。本文以该系统为例，主要论述了ATAM架构评估方法在该项目中的具体应用。首先，通过参考某云的工业互联网系统和该能源公司业务人员收集场景与需求；其次，结合收集的场景和需求，通过评估小组会议描述架构视图和场景实现；最后，通过评估小组会议确定系统质量属性，分析并构造属性模型，并对其中的一些权衡点做折中。通过以上架构评估的实施过程，最终项目顺利上线，获得了公司领导和用户公司的一致好评。

正文：
        随着工业互联网近年来的快速发展，很多电气、能源、电力等传统行业，也都纷纷开始打造工业互联网平台，以实现工业设备数据上云。在云端即可实时掌握设备的具体情况，还可以通过大数据做深度的数据分析和挖掘。进而提升产品的质量和市场竞争力。也正是基于这样的背景下，2020年3月，我们集团下属某能源公司也要为自己的产品如大型变频设备、储能设备打造综合能源服务工业互联网系统。
        该系统主要就是为了采集各种不同设备上报上来的数据，并对其进行解析、结构化，然后存储到数据仓库中，再进一步做数据的分析和挖掘，最终实现这些工业设备智能运维的目的。该系统的主要模块与功能有用户权限管理、物模型管理、产品管理、设备管理、固件管理、物联网卡管理、工单管理、采集并处理设备端上报的数据等等。另外，项目还集成了云之树、鎏云物联两家物联网卡代理商接口以便及时了解SIM卡流量和到期时间等情况，集成了高德地图做设备地图，集成了阿里云短信和友盟推送做消息通知。项目的开发、测试、产品经理等角色合计40余人，耗时十个月。我在项目中担任架构师角色，负责系统的整体架构设计工作。
        架构评估是软件开发过程中的非常重要的一个环节，在软件架构评估中我们通常关注的质量属性包括性能、可用性、安全性、可修改性等。性能是指系统的响应能力，即要多长时间才能对某个事件做出响应或者在某段时间内系统所能处理的事件的个数；可用性是指系统正常运行的时间比例，经常用两次故障之间的时间长度或出现故障时系统能够恢复正常的速度来表示；安全性是指系统能够向合法用户提供服务的同时可以阻止非授权用户访问的企图或拒绝服务的能力；可修改性是指系统能够快速地以较高的性能价格比对系统进行变更的能力，通常以某些具体的变更为基准，通过评估这些变更的代价衡量可修改性。
        为了更好的对我们系统的以上这些质量属性做评估和折中，我们使用了基于场景的评估方法-ATAM方法，下面将结合该项目的评估实践过程说明该评估方法我们是如何实施的。
        第一阶段，场景和需求收集。针对功能场景与需求的收集，主要是通过多次与该能源公司的领导与业务人员开需求会议收集而来。比如，在系统上需要看到每个工业设备的实时数据、故障报警的具体断面数据以供运维人员分析使用。另外，我们还参考了某云上相对成熟的工业互联网系统的功能与实现，从中提取了一些工业互联网应用的共性需求场景。比如，工业互联网系统包含的产品管理、设备管理、固件升级管理等需求都是共性需求，工业设备边缘网关与系统的通信场景、边缘网关固件升级过程场景等等都是共性场景。针对质量属性的场景与需求收集，主要也是来自于该能源公司业务人员，比如系统设备的实时数据请求时间延迟不能大于500毫秒、系统发生故障时需要在半小时内恢复正常、对已有功能的扩展修改调整需要在5天内完成、系统可以检测用户恶意行为并予以人工干预处理等等。
        第二阶段，架构视图与场景实现。在这个阶段，我们由多方人员包含产品、技术、业务人员、业务领导等组成了架构评估小组。首先，对ATAM的评估方法做了详细的介绍，让小组内成员都了解了整个ATAM评估的过程。然后，我作为架构师，对我们的架构视图做了详细的描述，主要包括我们所使用的系统架构为微服务架构，以及我们的架构可以如何实现之前收集的场景与需求。比如，针对产品管理、设备管理、物联网卡管理等系统基础功能，我们有一个专门的控制台微服务提供这些管理功能的增删改查操作；针对数据采集和通信的场景，我们有一个专门的数据采集处理服务；针对页面设备实时数据的展示的需求，我们有专门的websocket微服务，接收kafka的实时数据直接发给前端，也有专门的实时微服务，通过读取redis里的实时数据给前端展示。
        第三阶段，属性模型构造、分析与折中。经过评估小组多次会议之后，我们对单一的质量场景做了分析。性能方面，如设备的实时数据请求响应延迟不能大于500毫秒，设备历史数据的请求要求在2s以内响应；可用性方面，如系统出现故障时要求能在半小时内恢复正常；安全性方面，如系统可以检测用户恶意行为并予以人工干预处理；可修改性方面，如针对已有功能模块的扩展修改调整需要在5天内完成开发、测试、上线。除了单一场景的分析外，我们还对一些存在冲突的场景做了分析，如接口权限控制的控制粒度对系统的安全性和性能将产生影响，为了提升系统安全性，我们牺牲了少部分性能确保了每个接口统一做了接口权限验证。之后，我们输出了质量属性效用树，并对质量场景做了优先级排序，总体而言，对性能与安全性要求是最高的，其次依次是可用性、可修改性。
        该系统经过了以上的架构评估过程，所以在开发阶段都很顺利，同时也让该系统整体的安全性、可用性、性能等等方面都达到了设计的要求。系统在2020年12月已正式上线，之后陆续接入了该能源公司的很多工业设备，有高压变频设备、储能设备、消弧设备等，到目前为止大半年时间接入的工业设备就已经达到了200多台，每天设备上报的数据量也达到了三千多万条。另外，系统运行也相对稳定，并未出过重大故障，还受到了公司领导和用户的一致好评。
        但是还是存在一些不足之处，比如，采集处理模块，使用了Grooovy脚本做动态解析，而Groovy脚本很复杂，只有技术人员可编写修改，而且修改错误会导致使用该脚本的所有解析失效，针对这个问题我们后续还需要支持编辑脚本的时候做模拟解析测试以保证脚本的有效性，具体的做法是，在生效该解析脚本之前，必须先做模拟解析验证，即通过真实的数据做预解析，如果解析未报错，并且解析的数据是完整的则认为模拟解析通过，此时才可真正生效新解析脚本。所以，该系统其实还有很大的提升空间，我们后续会不断对系统进行演化，让该系统越来越好，力争在能源工业互联网领域能闯出一片天。

三 论文二：论基于架构的软件开发方法（ABSD）及其应用

摘要：

        2020年3月，本人所在的公司为集团下属某能源公司开发了一套工业互联网系统。该系统主要负责采集大型工业设备的遥测、遥信数据，再经大数据做实时或离线计算等分析，以达到工业设备智能运维的目的。我在项目中主要担任架构师角色，主要负责系统架构设计相关的工作。本文将以该系统为例，论述基于架构的软件开发方法在项目中的应用。首先，在架构需求阶段，通过参考某云与一些开源的物联网平台再结合业务方需求梳理出系统具体需求；其次，在架构复审阶段，采用基于场景的评估方法保障了项目的质量；最后，在架构演化阶段，灵活运用腾讯出品的TAPD来管理与控制需求的变动。使用了基于架构的软件设计方法，项目最终顺利上线，获得了公司领导层和用户的一致好评。

正文：
        随着工业互联网近年来的快速发展，很多电气、能源、电力等传统行业，也都纷纷开始打造工业互联网平台，以实现工业设备数据上云，在云端即可实时掌握设备的具体情况，真正实现设备智能运维。还可以通过大数据做深度的数据分析和挖掘，进而提升产品的质量和市场竞争力。
        2020年3月，我们集团下属某能源公司也要打造一套工业互联网系统，而我们集团研究院刚好承担了该系统的开发建设工作。该系统主要是为了采集各种工业设备的遥测、遥信数据，并对其进行解析、结构化，然后存储到数据仓库中，再进一步做数据的分析和挖掘，最终实现工业设备智能运维的目的。该系统的主要功能模块有用户权限模块、产品模块、设备模块、固件升级模块、物联网卡模块、工单模块、采集处理模块等等。另外，系统还集成了云之树、鎏云物联两家物联网卡代理商接口以便及时了解物联网卡流量和到期时间等情况，集成了阿里云短信和友盟推送做消息通知。项目的开发、测试、产品经理等角色合计30余人，耗时10个月。我在项目中主要担任架构师角色，主要负责系统架构设计相关的工作。
        在做系统架构设计时，我们经常会使用基于架构的软件设计方法（ABSD），该方法主要需要经历以下六个阶段：架构需求、架构设计、架构文档化、架构复审、架构实现、架构演化。在架构需求阶段，主要包含需求获取、标识构件、需求评审等活动，其中标识构件还可再细分为生成类图、对类图进行分组、把类打包成构件，这些活动之间往往会存在多次循环，才会形成最终的需求；在架构设计阶段，主要包含提出架构模型、映射构件、分析构件相互作用、产生架构、设计评审等活动，审计评审之后可能还会重新对构件映射做出调整，所以其中的活动也存在重复多次的情形；在架构文档化阶段，主要是对架构设计阶段的成果进行分析和整理后形成文档；在架构复审阶段，主要目标是标识潜在的风险，及早发现架构设计中的不足和错误；在架构实现阶段，包含的主要活动有分析与设计、构件实现、构件组装、系统测试等；在架构演化阶段，主要包含需求变动归类、架构演化计划、构件变动、变更构件的相互作用、构件组装与测试、技术评审等活动。
        在使用基于架构的软件设计方法时，我们在架构需求、架构复审、架构演化阶段，确实也遇到了一些问题。下面将结合我们项目中遇到的具体问题及我们的解决方案做进一步的阐述。
        架构需求阶段，通过参考某云与一些开源的物联网平台再结合业务方需求梳理出系统具体需求。由于我们我打造的物联网系统，业务方并不是非常清楚底层设备数据如何上云、上云需要什么支持等等，所以业务方对于底层具体功能并不能给出很好的建议。基于此原因，我们除了参考业务方提出的需求之外，还需要根据物联网系统常有的特性去进一步整理并细化功能需求。对于物联网平台，刚开始我们也没有非常深入的了解，所以我们想到了去参考某云的物联网平台、同时也去参考了一些开源的物联网平台的功能。最终，我们整理出了系统的整体功能需求和质量属性需求等。比如，数据采集处理模块、固件升级模块的需求、产品管理模块中的物模型管理等，我们更多的是直接参考了某云和物联网开源系统中的功能需求；又如，设备模块的管理需求、用户权限模块需求、工单模块需求等等，基本都是直接来自于业务方直接提出的需求。这些需求经过多次需求评审，业务方也经过了确认，最终形成了完整的架构需求。
        架构复审阶段，采用基于场景的评估方法保障了项目的质量。在架构复审阶段，我们要评估我们的架构是否能满足我们的功能需求和质量属性需求，所以我们采用了基于场景的架构评估方法-ATAM方法。首先是场景和需求收集，主要通过多次与该能源公司领导与业务人员开需求会议收集而来，同时某些场景也参考了某云物联网平台和一些开源的物联网平台。其次是架构视图与场景实现，我们由多方人员包含产品、技术、业务人员、业务领导等组成架构评估小组，之后对ATAM的评估方法做了详细的介绍，让小组内成员都了解了整个ATAM评估的过程，再对我们的架构视图做了详细的描述，主要包括我们所使用的系统架构为微服务架构以及我们为何使用微服务架构，还描述了我们的架构可以如何实现之前收集的场景与需求。最后是属性模型构造与分析、折中，经过评估小组多次会议之后，我们对单一的质量场景做了分析，针对多场景交互的权衡点做了折中，最终输出了质量效用树，也分析出了其中的风险点、敏感点、权衡点等。
        架构演化阶段，灵活运用腾讯出品的TAPD来管理与控制需求的变动。在架构演化阶段，刚开始需求变动频繁是很正常的事情，而有些需求的变动可能影响的构件是多个，如果没有对这些需求做归类记录跟踪，变动的需求最终能否落实会变的非常不可控。所以，管理好需求变动就非常有必要了。此时，我们使用了腾讯出品的TAPD平台，在该平台，我们项目维护了一个需求池，需求池里都是用户提出的需求，然后我们几周会有一次迭代，每次迭代其实就是一个架构演化计划，而每一次迭代都会从需求池里拿出比较紧急重要的需求放到迭代中。放入迭代中的同时，会先对需求进行归类打标签，其中一类标签就是归属构件，已有的构件我们已提前维护成了字典，标签里直接勾选即可。同时，我们也会把需求具体负责人填上，这就做到了需求到具体责任人。每一次架构演化之后，我们都会开一次会议针对演化过程做复盘，主要是复盘其中做的好的点与不好的点，好的在项目后续演化会继续推广，而不好的在后续演化中要逐步调整优化。
        该系统因为使用了基于架构的软件开发方法，所以在开发阶段都很顺利，同时也让该系统的可扩展性、重用性等等方面都达到了设计的要求。系统在2020年12月已正式上线，系统上线后也已经做了多轮演化，同时也陆续接入了该能源公司的很多工业设备，有高压变频设备、储能设备、消弧设备等，到目前为止大半年时间接入的工业设备就已经达到了200多台，每天设备上报的数据量也达到了三千多万条。另外，系统运行也相对稳定，并未出过重大故障，还受到了公司领导和用户的一致好评。
        但是还是存在一些不足之处，比如，采集处理模块，使用了Grooovy脚本做动态解析，而Groovy脚本很复杂，只有技术人员可编写修改，而且修改错误会导致使用该脚本的所有解析失效，针对这个问题我们后续还需要支持编辑脚本的时候做模拟解析测试以保证脚本的有效性。所以，该系统其实还有很大的提升空间，我们后续会不断对系统进行演化，让该系统越来越好，力争在能源工业互联网领域能闯出一片天。

四 论文三：论软件系统架构风格

摘要：

        2020年3月，本人所在的公司为集团下属某能源公司开发了一套工业互联网系统。该系统主要负责采集大型工业设备的遥测、遥信数据，再经大数据做实时或离线计算等分析，以达到工业设备智能运维的目的。我在项目中主要担任架构师角色，主要负责系统架构设计相关的工作。本文将以该系统为例，论述架构风格在项目中的具体应用。首先，通过采用面向对象的架构风格，抽象出了很多的对象和行为如用户、产品、设备、物联网卡、产品创建与发布、设备创建投入与退出等；其次，采用了事件驱动，保证了工单状态的变更的同时也能及时通知到相关用户；最后，采用了解释器风格，让系统可以解析不同报文格式的采集数据。使用适合系统的架构风格，让项目最终顺利上线，获得了公司领导层和用户的一致好评。

正文：
        随着工业互联网近年来的快速发展，很多电气、能源、电力等传统行业，也都纷纷开始打造工业互联网平台，以实现工业设备数据上云，在云端即可实时掌握设备的具体情况，真正实现设备智能运维。还可以通过大数据做深度的数据分析和挖掘，进而提升产品的质量和市场竞争力。
        2020年3月，我们集团下属某能源公司也要打造一套工业互联网系统，而我们集团研究院刚好承担了该系统的开发建设工作。该系统主要是为了采集各种工业设备的遥测、遥信数据，并对其进行解析、结构化，然后存储到数据仓库中，再进一步做数据的分析和挖掘，最终实现工业设备智能运维的目的。该系统的主要功能模块有用户权限模块、产品模块、设备模块、固件升级模块、物联网卡模块、工单模块、采集处理模块等等。另外，系统还集成了云之树、鎏云物联两家物联网卡代理商接口以便及时了解物联网卡流量和到期时间等情况，集成了阿里云短信和友盟推送做消息通知。项目的开发、测试、产品经理等角色合计30余人，耗时10个月。我在项目中主要担任架构师角色，主要负责系统架构设计相关的工作。
        在做软件架构设计的时候，为了提高系统的复用性和提升开发效率，我们通常会采用一些架构风格。我们经常采用的架构风格主要有：数据流风格、调用返回风格、独立构件风格、虚拟机风格、仓库风格。数据流风格将前一步处理的结果作为后一步的输入内容，主要包含批处理序列与管道-过滤器两种风格，批处理序列强调的是大量整体的数据一起处理，而管道过滤器强调的是流式数据的处理；调用返回风格主要包含主程序/子程序、面向对象风格、层次结构三种风格，主程序/子程序是面向过程的调用，面向对象风格主要是对象方法的调用，层次结构则是层与层的方法调用；独立构件风格强调的是构件之间不直接交互从而降低系统的耦合性，主要包含进程通信与事件驱动两种风格；虚拟机风格的特点是可以灵活的自定义场景，主要包含解释器风格与规则系统，而规则系统其实是在解释器的基础之上增加了经验规则；仓库风格强调的是以数据为中心，主要包含数据库系统、黑板系统、超文本系统三种风格。
        以上五大类经典的架构风格，并非在系统中都要全部用上，而是根据系统的具体情况选择合适的架构风格。所在，该系统中就选用了其中三种架构风格：面向对象架构风格、事件驱动和解释器架构风格。下面将结合该系统描述这三种架构风格是如何实施的。
        第一，面向对象架构风格。该风格要求我们在前期要尽可能的识别出系统中的对象和相关的行为信息，所以，我们一开始就根据系统的需求，对系统中所包含的对象和行为做了识别。首先，我们根据项目需求，识别并抽象出了很多的对象，如用户、产品、设备、物联网卡、OTA固件、物模型、工单、故障记录、报警记录等。另外，还抽象出了对象的行为，如产品的创建、产品的编辑、产品物模型配置、产品采集配置、产品解析脚本配置、产品发布、产品下线、设备创建、设备编辑、设备投入、设备退出、设备升级固件、设备更新配置、设备关联物联网卡等等。然后，所有的交互，基本都是对象对另一个对象的方法调用，如设备升级固件需要获取固件信息则是设备对象调用了OTA固件对象获取到了固件的信息、设备关联物联网卡获取物联网卡信息时也是通过设备对象去调用物联网卡对象的方法、写入故障报警记录时需要调用设备对象的方法查询设备信息等等。
        第二，事件驱动架构风格。由于该系统的主要目的是要做智能运维，所以，系统的工单的状态变更信息、设备故障报警信息等都需要及时的通知到系统的各类用户，此时我们就使用了事件驱动的风格。如当系统的工单状态从待派单变成已分配区域需要通知到区域经理，从已分配区域变成已派单需要通知到运维人员等等。而通知为了确保高到达率，同时使用了短信通知与友盟推送。其中工单状态变更过程并不需要关心通知情况，这刚好满足我们事件驱动风格的特点。所以为了解耦工单状态变更与通知的过程，我们引入了消息中间件，工单的状态变更事件直接发到消息中间件，通知推送处理模块通过订阅工单的状态变化给系统的各类用户推送APP消息和发送短信通知。另外，当设备产生了故障信息、报警信息时，我们除了要把这些记录写入数据库之外，还会把这些故障、报警信息推到消息中间件，然后通知推送处理模块通过订阅这些故障报警信息，通知到相应的运维人员。
        第三，解释器架构风格。因为该系统采集到设备上报的报文要支持二进制、json等格式，而报文的具体内容参数都不是固定的，针对不同的设备可能会有所不同，所以这就要求系统可以根据具体的设备类型解析出上报的遥测遥信信息。而虚拟机风格中的解释器风格刚好能满足我们的要求，该风格的优点是可以灵活的应对自定义的场景。我们使用了Groovy脚本方式来解析报文，具体做法是将采集的遥测、遥信报文数据附带上设备的必要信息，传入到封装好的数据解析器中，而解析器主要是使用Groovy脚本进行解析并将解析后的固定格式的报文数据返回，至此，报文解析工作就此完成。这种方式，对产品的Groovy脚本的维护要求很高，因为Groovy脚本的复杂度很高，只有专业技术人员才能编写，所以针对这个问题，我们根据现有的几种报文格式，编写了多个报文模板，在产品里维护Groovy脚本只需要选择其中的模板即可，即使后续有添加脚本基本都是我们技术人员参考现有的Groovy脚本去添加Groovy脚本。
        该系统因为使用了以上三种架构风格，所以在开发阶段都很顺利，同时也让该系统的可扩展性、松耦合性、重用性、可修改性等等方面都达到了设计的要求。系统在2020年12月已正式上线，系统上线后，陆续接入了该能源公司的很多工业设备，有高压变频设备、储能设备、消弧设备等，到目前为止大半年时间接入的工业设备就已经达到了200多台，每天设备上报的数据量也达到了三千多万条。另外，系统运行也相对稳定，并未出过重大故障，还受到了公司领导和用户的一致好评。
        虽然，使用架构风格的实践效果显著，但是还是存在一些不足之处，比如，我们所选用的解释器风格，由于Groovy脚本很复杂，只有技术人员可编写修改，而且修改错误会导致使用该脚本的所有解析失效，另外由于使用了Groovy脚本也牺牲了部分的性能，针对后期数据量越来越大可能会有一定的影响。所以，该系统其实还有很大的提升空间，我们后续会不断对系统进行演化，让该系统越来越好，力争在能源工业互联网领域能闯出一片天。

五 总结

三篇论文仅仅是达到了及格的标准，其中也许存在很多逻辑不严谨的地方，大家仅需要参考其中的套路，不必纠结其中的细节。
最后，祝看到本文的朋友今年顺利拿证。