基于模式的软件自动化生产方法探究,包括自动化专业在内的模式识别和智能系统的本科阶段是什么...

基于模式的软件自动化生产方法探究

模式识别和智能系统包括自动化专业的哪个本科阶段...自动化专业本科阶段涉及工程技术基础和电气技术、电子技术、控制理论、自动检测与仪器仪表、信息处理、系统工程、计算机技术与应用、网络技术等更广泛领域的某些专业知识。它可用于运动控制、工业过程控制、电力电子技术、检测和自动化仪器、电力

自动化专业考研中\"模式识别与智能系统\"和\"控制理论...

模式识别主要集中在计算机视觉上，这在最近几年仍然非常流行，需要编程。 如果你被雇佣了，你会更经常去软件公司。 双控制主要是控制理论、plc、dsp控制等方面的研究，倾向于单片机应用或理论研究。 软件和硬件都是可以接受的。 我写了这么多，可编程控制器:西门子S7-200，214+输入输出模块传感器:感应接近开关，电容接近开关执行元件:电机，气缸，电磁阀，其他:开关，按钮，DC电源，终端，控制箱，导轨，信号灯，继电器，接触器，当在空闲模式下使用计算机时:计算机+采集卡+配置软件+通信电缆+，这个主要的就业领域非常广泛，但不要去任何机床厂等，了解更多关于控制类型和单片机连接机械，工资要高得多 你认为你应该多学点控制和单片机，然后接触机械，哈哈~ ~ ~ ~，你认为机械太简单了，机械是一门非常实用的学科，在大学里学的专业知识只是机械，中国科学院自动模式识别国家重点实验室 官方英文翻译是:中国科学院自动化研究所模式识别国家实验室，希望能帮助您，欢迎来电咨询 欢迎领养！平面仓库(Flat warehouse)是指货物放置在地面或普通货架上(通常小于7米)，进出立体仓库的货物由叉车手动放置在高层货架上(通常小于22米)。在软件的控制下，太原刚玉自动化立体仓库的自动入库和出库通过提升设备实现:各种搬运机械的无人无缝连接，实现整个仓库的无人操作。

包括自动化专业在内的模式识别和智能系统的本科阶段是什么...

模式识别和智能系统包括自动化专业的哪个本科阶段...自动化专业本科阶段涉及工程技术基础和电气技术、电子技术、控制理论、自动检测与仪器仪表、信息处理、系统工程、计算机技术与应用、网络技术等更广泛领域的某些专业知识。它可用于运动控制、工业过程控制、电力电子技术、检测和自动化仪器、电力

自动化专业考研中\"模式识别与智能系统\"和\"控制理论...

基于模式的软件自动化生产方法探究范文

摘要:在当前的软件开发理论和实践中，软件生产需要从需求到代码完成手动完成。从需求分析到架构的对应和转换仍然依赖于软件设计者的技能、经验和创造力。大多数软件代码生产仍然需要程序员手工完成。这种传统的软件生产方法给软件业带来了许多问题。随着软件工程理论和案例工具的发展，突破传统软件开发方法的方法论逐渐被提出。基于模式的软件自动生产模式可以节省从软件抽象模型到软件代码自动生成过程中的大量人力，提高软件开发效率，增加软件适应性。本文通过介绍基于模式的软件自动化生产模式，重点研究软件体系结构的设计。

关键词:建筑；设计模式；自动化生产；发展效率；自我适应；

摘要:在当前的软件开发理论和实践中，从需求获取到代码完成，软件生产需要手工完成。从软件需求分析到软件架构的映射仍然需要设计者的技能、经验和创造力。大多数软件代码生产仍然依赖程序员手动完成。这种传统的软件生产方式给软件业带来了许多问题。随着软件工程理论和案例工具的发展，突破传统软件开发方式的方法论逐渐被提出。基于模式的软件自动化生产方法可以在软件抽象模型到软件代码自动生成的过程中节省大量的人力。这种方法提高了软件开发的效率，增加了软件的适应性。本文通过引入基于模式的软件自动化生产方法，研究了模型驱动软件体系结构的设计。

关键词:建筑；设计模式；自动化生产；发展效率；适应；

1，导言

在高需求、高投资、高竞争的环境下，软件生产的规模和效率已经成为软件企业最重要的问题之一。在传统的软件开发过程中，大多数软件代码的生成依赖于程序员的手工工作，这给软件开发带来了很多问题。首先，软件生产效率低，项目延迟率高。其次，软件质量难以保证。第三，技术更新快，软件移植性差。最后，软件产品很难修改和维护。

随着软件开发理论的发展和完善，传统的软件开发方法已经不能满足社会和企业的需求，新的软件开发方法应运而生。OMG提出了基于UML的模型驱动体系结构(MDA) [1]，指出了从软件抽象模型到软件代码自动生成的良好方向。团队系统，一个支持软件工厂[2的工具，被添加到微软发布的VS.Net 2005。以软件自动化生产为特征的软件生产模式已经成为新的热点。

事实上，各种新的CASE工具正在悄悄地改变软件开发模式。然而，自动化软件生产的时代不会很快到来。软件生产自动化不仅是少数软件工具，也是软件开发的一种新方法。它要求管理者和开发人员改变传统的开发概念，以便技术积累和过程管理能够适应新的开发模式。

独立的自动化方法已经存在于软件开发的各个阶段。在需求阶段，为了便于理解和沟通，资源、组织和基于业务的需求模型(ROB) [3]使用递归分解方法分别从资源、组织和业务中提取需求。ROB的全球统一树结构促进了需求对象的正式定义，以实现计算机中的存储和管理。在规范需求变更管理组织和流程的基础上，建立数据模型，设计数据操作语言，定义操作界面，通过编辑和修改对象模拟需求变更，在完整性和一致性规则像代码契约这样的编译时扩展是好的，但是正式发布的扩展需要几年的时间才能发展成熟和稳定。由于有许多不同的领域，每个领域都有自己的问题，官方的扩展不可能涵盖所有问题。的约束下，自动完成由需求变更引起的完整操作模块。

在设计模式阶段，验证先决条件可以被视为设计模式，因为它是对正在进行的问题的可重复解决方案。微软的代码契约是设计模式自动化的完美例子。基于本机C#或Visual Basic，它提供了一组表示检查规则的应用编程接口。规则的具体形式包括前置条件、后置条件和对象不变量。

[14]

2，模型驱动架构(MDA)

2.1，MDA概述

模型驱动架构的核心思想(见图1)是抽象一个独立于实现技术并完全描述业务功能的核心平台独立模型(PIM)。然后，根据不同的实现技术制定多个转换规则，并通过这些转换规则和辅助工具将PIM转换成与特定实现技术相关的平台特定模型(Platform Specific Model，PSM)。最后，PSM被转换成代码。与传统的软件开发方法相比，模型驱动开发注重模型，项目管理开发容易，提高了软件生产效率。在从个人信息管理到个人信息管理的转换过程中，一对多转换是可能的，这增加了软件开发[1]的可移植性。软件工厂可以被认为包含MDA，并在此基础上进行了扩展，这比基于PIM和PSM [2]的MDA定义更广泛。

图1模型驱动架构

2.2，基于模式的转换方法

基于模式的转换方法(mode-based conversion method)是一种由模型驱动架构生成的方法:模型使用一种形式和意义定义精确的语言来描述系统，从而适合于计算机的自动解释。模型之间的转换需要定义一组转换规则来描述源语言中的元素如何转换成目标语言中的元素。

在基于模式转换的MDA中(见图2)，转换由两个步骤组成:转换规则和转换操作。转换规则定义转换前后的条件，当满足转换规则时，执行转换操作；转换操作是从模式库中找到模式，然后调用模式实现模型的转换，完成元模型元素到相应目标模型元素的转换。在此过程中，模式库中的模式不足。此时，有必要定义转换规则，完成模型转换，然后将其定义为新模式，并将其存储在模式库[4]中。

图2基于模式转换的MDA

3，模式

之后，我们不再关心用于软件转换的特定语言和工具，而是专注于基于模式的软件自动化开发方法中模式的研究。

模式驱动软件自动生成方法中的模式分为需求阶段、设计阶段和实现阶段，主要研究从需求到软件体系结构的实现。第4节将软件架构模式系统[5]和问题框架[6]等辅助工具引入该方法，以便更好地从需求阶段过渡到软件架构设计阶段。

3.1，模式概述

模式[7]是指从生产经验和生活经验中提炼提炼出来的核心知识体系。该模型实际上是解决某种问题的方法。解决某一类问题的方法可以归结为一个理论层面，即模型。模式是一种参考性的指导策略。在良好的指导下，初学者可以利用训练有素的软件工程师的集体经验。它们记录了在软件开发领域中久经考验的经验，并有助于促进良好的设计实践。

模式这个词涉及的范围很广，它标志着对象之间隐藏的规则关系。这些对象不一定是图像或模式，而是数字、抽象关系，甚至是思维方式。只要它是重复发生的，就可能有某种模式[7]。亚历山大给出了一个经典的定义，即每种模式都描述了一个在我们环境中不断发生的问题，然后描述了解决问题的核心[8]。

一般来说，模式=模式名+问题+解决方案+效果。模式名用两个词来描述模式问题、解决方案和效果。问题描述应该何时使用该模式？该解决方案描述了设计的组成部分、它们的相互关系、它们各自的责任和合作方法；效果描述了模式的使用效果以及使用模式时需要权衡的问题。

3.2，基于模式的MDA方法中的模式

在基于模式的主成分分析方法中，需求分析师在获得需求后，使用需求模式来描述需求。平台无关模型的建立从传统软件开发方法中的需求分析到底层设计阶段，采用架构模式和设计模式。在传统的软件开发方法中，平台相关模型的建立是从底层设计到编码阶段，采用了一种示例模式。

3.2.1，需求分析阶段

除了不相关的系统之外，所有系统的需求本质上都是相似的。例如，每个系统都有许多查询功能，每个功能都有自己独特的需求。当定义一个业务系统时，相当一部分需求属于相对较少的类型。因此，有必要以一致的方式定义相同类型的所有需求。

需求模式:描述定义特定需求类型的方法，[9】。需求模式适用于单个需求，有助于一次定义单个需求。模式的任务在需求者编写需求时结束，但是开发人员和测试人员可以根据需求获得工作提示和测试方法。

需求模型包括以下元素:基本细节、适用性、讨论、内容、模板、示例、附加需求、开发考虑和测试考虑[9】。

使用需求模型的好处:1)需求模型提供指导，例如建议包含什么信息、建议、常见缺陷提醒，并指出其他应该考虑的问题；2)需求模型节省了时间，不需要从头开始编写需求。该模型为发展提供了合适的起点和基础。3)需求模式促进了同一类型需求的一致性。

需求模型让开发人员有机会确定一种需求所依赖的基础设施，而无需考虑任何一个需求。单一需求位于食物链的下游；该设计位于食物链的上游，并根据需求提供食物。马丁·福勒的分析模式[10]在需求模式的另一边。分析模式高于食物链中的需求模式，而设计模式则轮流以需求模式和分析模式为基础。

3.2.2，设计阶段模式

每个模型都是一个由三部分组成的规则，解释特定背景、问题和解决方案之间的关系。作为现实世界的一个元素，该模型描述了一个特定的背景，在这个背景下反复出现的一系列力，以及消除这些力的空配置。作为语言元素，模式提供了如何在相关上下文中重复使用这种空配置以消除一系列给定力的指导。简而言之，这个模型既是一个过程，也是一部作品，它描述了一部充满活力的作品，并解释了作品《[》的创作过程。

理论上，模式分类有助于选择可能有助于解决给定设计问题的模式。当开始确定粗粒度设计时，可以使用架构模式。设计模式可以在整个设计阶段使用；在实施阶段可以使用示例模式。

软件架构模式[5]描述了在特定设计情况下反复出现的设计问题，并提供了经验证的通用解决方案的总结。解决方案摘要描述了模式的组件、它们的职责和关系，以及这些组件如何协作。架构模式描述了基本的软件系统组织大纲，提供了一组预定义的子系统，指出了这些子系统的职责，并包括了组织子系统之间关系的规则和指南。

设计模式[5]提供了改进子系统、软件系统组件或它们之间关系的大纲，描述了组织组件相互通信的通用结构，并可以解决特定背景下的一般设计问题。

软件体系结构的子系统及其关系通常由几个较小的体系结构单元组成(由设计模式描述)；设计模式是一种中型模式，比架构模式小，但独立于编程语言和编程范式。

3.2.3，实施阶段模式

例[5]是一种低级模式，它针对特定的编程语言。示例说明了如何使用给定语言的功能来实现组件的特定方面或组件之间的关系，促进程序员之间的通信，以及提高软件开发和维护的速度。

与设计模式中阐述的一般结构原理不同，示例描述了如何在特定编程语言中解决特定的实现问题，也可以描述设计模式的特定实现，因此它们之间的界限并不清楚。例子可以直接解决与语言使用相关的低级问题。

在代码实现级别，为任何给定模式提供完全通用的实现是不可行的。与完全通用的实现相比，定制的、特定于应用程序的和特定于域的模式实现，以及在框架和产品线架构中可见的实现，是更简单和更有效的选择。

3.3，模式详情

无论是单一架构模式还是多种架构模式的组合，它都不是完整的软件架构。它只为软件系统提供了一个架构框架。它必须进一步标准化和细化，包括集成框架和应用程序的功能，以及细化软件系统的组件及其关系。这些任务可能需要通过设计模式和示例来完成。选择一种或多种架构模式只是软件系统架构设计的第一步。

模式不是孤立的；每个模式通常与其他模式相关联。GoF使用“设计模式”中的图片来显示书中提到的23个模式之间的依赖关系，并使用“相关模式”部分详细介绍每个模式[12]。通过对“好的”软件体系结构的分析，可以得出结论，在使用模式[5]中，高密度和紧密集成通常是首选的。这些模式相互补充和完善，并以各种方式组合成一个更大的结构。

文献[5，13]认为一些模型的应用促进了设计，并提供了新的特征和可能性。其他模式的应用可视为设计的完美。这种完美不是指将设计推向一个新的方向并获得一种新的能力，而是使现有的设计完整，原始设计能够在合作中达到其逻辑终点。竞争模式提供了另一种选择来激发设计对话，而合作模式依赖于另一种设计的互补性来完善设计。

3.3.1，模式分类

模式分类有助于选择可能有助于解决给定设计问题的模式。根据具体的模式，不同的作品有不同的分类方法，甚至包含不同类型的模式。

GoF并不将MVC视为模式[12]，但在模式分解方面已经得出了类似的结论:观察者用于通知，复合用于嵌套视图，策略模式用于参数化控制器行为，可选的工厂方法(Factory Method)用于为系统指定默认的控制器类，装饰器(Decorator)可用于向视图添加特征。

Frank Buschmann等人将具体模式分为14组，[5]帮助用户大致识别模式，并为选择模式提供指导。GoF将模式分为三类:创造模式、结构模式和行为模式[12]。

4，辅助工具

4.1，软件架构模式系统

为了帮助开发高质量的软件系统，一个软件架构模式系统[5]应运而生。模式系统链接模式并描述模式如何相互关联和互补。模式系统必须符合以下规则[5]:包含足够的模式；统一描述所有模式；揭示模式之间的各种关系；组织模型；可以帮助构建软件系统；可以继续发展。

为了便于学习和使用，模式系统中的模式被分类。从两个维度进行分类，一个是模式类别，如建筑模式、设计模式和实例；二是问题范畴，如从混沌到有序、分布式系统、交互系统、适应性系统、结构分解、工作组织等。

模式系统为管理大量模式提供了一种方便的方式:所有模式都以统一的方式进行描述；通过分类，用户可以对模式有一个大致的了解。提供合理的搜索策略，帮助用户选择模式；为使用模式开发软件系统提供指导，并充分发挥模式的力量[5】。

4.2，问题框架

为任何模式提供完全通用的实现是不可行的。因此，当上下文改变时，适用于一个或一类应用程序模式的实现可能不再适用。为了提高设计和代码的可重用性，可以找到在这些限制下的可重用技术，例如框架、产品线体系结构和生成工具。

框架通常定义设计参数，例如整体结构类和应用系统对象之间的关系，以便具体的应用实现者能够专注于应用本身的特定细节。该框架主要记录软件应用程序中常见的设计决策。框架强调设计重用，所以设计模式必须在框架设计中使用。框架实现可以提供绑定特定模式的机制。

为了方便、正确地理解和使用模型，引入了迈克尔·杰克逊的问题框架[6]。问题框架的概念绕过了深入分析的“分析和设计的集成”方法:理解问题域本身而不接受编程世界的隐喻和结构。问题框架是一类问题的概括，给出了问题的清晰描述和可能的解决方案。

问题框架和模型具有良好的兼容性，两者都力求具体。问题框架可以为一些关键模式提供合适的上下文。从分析模式的角度来看问题框架，在它的上下文中只有几个解决方案。问题框架提出了定义问题世界的主题，但不涉及解决方案的内容。基于模式的开发方法试图通过理解将由模式[解决的问题的背景下的驱动力来确定问题的边界。另外，设计模式有助于理解框架结构，掌握设计模式是分析系统的利器。

问题框架描述了增强的和详细的意图，抓住了问题区域的本质及其对解决方案的约束，并提供了模式组合的方法。开发人员可以通过定义一个合适的边界来关注设计。

4.3，软件适应性和自动化生产模式

软件自适应(Software self-adaptation)是指软件在运行时检测环境及其自身状态的变化，以确保持续的高质量服务，并相应地主动调整自身行为的活动。适应性软件的基本周期是“感知-决策-执行”[14。

在基于模式的软件自动化生产模式中，软件架构模式和设计模式贯穿自适应软件的每个周期，为自适应软件的构建提供技术支持。软件体系结构包括开发阶段的静态实体和运行时的软件体系结构，它们可以在至少两个阶段为软件适配提供支持:在感知阶段获取体系结构信息；在执行阶段，体系结构可以动态调整[15]。

为了构建和实现自适应软件，拉米雷斯等人总结了12种软件设计模式，包括传感器工厂、基于案例的推理和服务器重新配置[16]；Schmidt等人总结了一系列可用于自适应中间件的设计模式，并已应用于中间件TAO和ZEN等人的[17]；Gomma等人提出了主/从、客户机/服务器、非集中式控制和运行时软件重新配置的其他模式，[18]。

软件自动化生产模式和软件自适应相辅相成。该软件是自适应的。当环境和其他影响环境发生类似变化时，一种类型的应用软件的实现可以容易地转换成另一种类型的应用软件。软件自动化生产模式的实现使软件在自适应方面得到进一步发展。

5，思考和总结

5.1，问题和思考

软件的自动化生产会遇到四个内在的困难:1)如何清晰准确地解释软件的需求、设计和功能，使开发者容易理解；2)如何使开发团队成员对软件有统一正确的理解；3)如何在需求变化后快速做出指导和响应；4)如何清楚地理解从软件开发过程中抽象出来的模型？当软件环境改变时，这些困难会使自动开发更加困难。解决上述困难需要统一的沟通方式和适应变化的能力。

软件生产能自动化吗？文献[19]描述了软件产品和一般物理产品的区别:软件产品在某些方面类似于传统工程学科中的物理产品，但也有一些重要的区别使得软件开发不同。由于软件是一个逻辑概念而不是物理对象，它的成本集中在开发过程而不是生产过程中。此外，因为软件不会磨损，它的可靠性取决于逻辑质量(如正确性和健壮性)，而不是物理质量(如硬度和韧性)。

理解生产和开发之间的区别有助于思考自动化软件生产的实现。当需求确定，生产工艺规范统一后，软件可以自动批量生产。产品自动化大规模生产的前提是:需求确定和规格确定。如果完全确认，只需要一份副本。如果确定了功能要求，但组合不同，则需要修改配置。

5.2，问题解决

解决具体问题的适当方法如下:首先，需求分析师获得需求，并用需求模式描述需求；其次，根据需求模式的描述，提出了可能影响问题解决的驱动力。然后，给出了各种可能的解决方案。最后，讨论了这些解决方案的优缺点。定义系统时，查询所有需求模式字段以确定系统的相关字段，并且只关注所选字段的模式。

典型的电子商务应用程序对需求进行分类并处理大量数据，但是对数据只执行相对简单的计算，主要是查询功能。对于这种特定的领域，模式模型的转换规则可以预先确定，因此实现模式驱动的软件自动开发方法是可行的。对于需求建模，模型转换过程可以定义为数据表处理模式、查询处理模式和其他处理模式。并定义各处理模式的程序模板和实体对象，实现从电子商务应用模型到平台相关模型的转换。

该模式指导开发人员思考问题的本质以及解决问题时需要考虑的问题。该模式起着指导作用，所有活动都在开发人员自己的控制之下。该模式可以帮助开发人员进行设计推导，但其设计的合理性仍需验证。尽管模式限制了一些自由，但它们并不妨碍开发人员做出选择，并且通过指定设计的效果和成本使选择过程更加清晰。

模式写作中有许多模式是成对的，它们本质上解决了同一个问题。如果多个模式解决同一个问题，应该选择哪一个？开发人员需要综合更多的信息来获得合理的选择，并结合自己在软件开发中的经验来理解问题解决的背景和驱动力。开发人员获得的信息量和对信息的理解、模式的背景、驱动力、优势和额外成本都是影响选择的条件。

5.3，分析总结

软件模式系统是在基于模式转换的MDA基础上引入的，这使得基于模式的软件自动开发方法不同于传统的模式驱动软件开发方法:模式从需求作用于系统，从需求到架构的映射自然过渡，特定系统中的模式转换可以预先确定，基于模式的软件自动开发方法的自动化成为可能。

基于模式的转换方法需要首先建立包含相对完整设计模式的模式库。该模式系统解决了模式转换过程中模式库的建立问题，为添加新的模式样式提供了指导。

软件架构模式系统的引入为开发人员提供了在软件开发中如何实现、组合和使用这些模式的指导方针。它包含一系列软件架构模式，但它只适用于软件架构模式、设计模式、示例和其他设计阶段。为了实现软件从需求到代码实现的自动化生产，有必要引入需求模式，并与软件架构模式一起形成软件模式系统。

需求模式将需求分成不同的领域。将这些领域集成到模式系统中可以为特定的需求领域产生模式系统，涵盖从分析到使用特定编程语言的特定设计的大多数软件开发过程。

引入需求模式后的模式系统解决了软件自动化生产过程中的统一通信模式，而模式驱动架构生产模式解决了软件生产过程中的软件环境变化问题。

模型驱动架构中模式的使用不限于转换过程，而是将用于建立平台无关模型和生成平台相关模型的过程。平台无关模型的建立需要利用形式化方法的模糊性来描述系统。需求模式的引入简化了形式描述，并为从需求到架构的转换铺平了道路。平台相关模型的生成需要平台特定技术和平台提供的架构的结合。

软件开发一直是一项需要创造性思维的工作，软件技术的进步一直是渐进的。软件需求的变化将导致软件架构的变化。在这个过程中，计算机很难做出适当的选择，软件开发人员需要进行思考和决策。基于模式的软件开发方法需要在需求分析阶段开发，因此需要特定领域的专家和分析师来开发它。在设计阶段，您需要非常熟悉不同平台、不同系统架构和所用转换工具的转换定义，因此您需要专业开发人员，这在初级开发人员中很难推广。软件自动开发方法遇到的四大固有困难会使软件环境发生变化时自动开发更加困难，这都导致软件自动开发方法的研究进展缓慢。

结论软件开发设计过程涉及多种不同类型和不同层次的思维过程。程序员做的大量工作都集中在抽象层次较低的软件编码上。他们过于习惯性地依赖于特定的解决方案，并且不具体检查解决方案是否合适和有效。软件生产自动化的研究并不是完全的自动化，需要开发人员思考和做出决策。基于模式的软件自动化生产方法仍然有很大的发展空。当前的模式选择和决策依赖于程序员的经验和思考，这经常导致许多主观错误。因此，转换决策的制定和模式选择中要考虑的因素的优先性是未来的研究方向。设计模式阶段所需的总体框架也是未来的研究方向。本文分析了模式驱动软件体系结构设计在电子商务应用领域的可行性，进一步具体实现是未来的研究方向。

参考:

[1]模型驱动架构[电子商务/其他]。[2017-08-25]。https://en.wikipedia.org/wiki/Model-driven_architecture.

[2][软件工厂。[2017-08-26]。https://en.wikipedia.org/wiki/Software_factory.

郭新峰，马世龙，卢江华，等。需求变更的自动管理模型及实现[。计算机系统应用，2015，24 (4) :11-18。

刘魁，宋淼，陈逸飞，等.基于软件模型的产品信息管理到产品服务管理的模型转换.《计算机技术与发展》，2006，16 (10) :74-76。

[5]布希曼，梅尼耶，罗纳特，等.模式化软件架构(第1卷:模式系统[]。纽约:约翰·威利父子公司，1996年。

[6]迈克尔J .问题框架:分析和构建软件开发问题[M]。爱迪生-韦斯利，2001年。

[7]模式[EB/ol]。[2017-07-12]。http://www.mie168.com/zhuantini/moshi.htm.

[8]模式[eb/ol]。[2014-06-24]。http://www.baike.com/wiki/mode.

软件需求模式[·米】。微软出版社，2014。

[10]福勒分析模型[。北京:机械工业出版社，2004。

[11]亚历山大·C .[永恒的建筑方式。牛津大学出版社，1979年。

[12]埃里克·G，理查德·H，拉尔夫·J，等.设计模式——可重用面向对象软件的元素[·M]。爱迪生·韦斯利，1995年。

[13]BUSCHMAN F，HENNEY K，SCHMIDT D，等.模式化软件体系结构(第5卷:关于模式和模式语言[M .)。纽约:约翰·威利父子公司，2007年。

丁波、王怀民、石殿西。构建具有自适应能力的软件[。软件杂志，2013，24 (9) :1981-2000。

[15]克莱默，马吉，自我管理系统:一个架构上的挑战[，软件工程未来会议录，2007

开发动态自适应系统的设计模式[。密歇根州立大学，2008年。

[17]SCHMIDT D，STAL M，ROHNERT H，等.面向模式的软件体系结构(第2卷:并发和网络对象的模式[M .)。纽约:约翰·威利父子公司，2001年。

[[18]高美华，侯赛因.软件体系结构动态演化的软件重构模式[.第四届IEEE/IFIP软件架构工作会议，2004年(WICSA，2004年)。

[19]韦格纳《软件技术的研究方向》，[，第三届国际软件工程会议录，1978年