下载文档原格式
1、软件工程的生命周期：需求分析阶段；系统分析与设计阶段；系统实现阶段；测试阶段；维护阶段。
2、建模的目标是：（1）便于开发人员展现系统；（2）允许开发人员制定系统的结构或行为；（3）提供指导开发人员构造系统的模板；（4）记录开发人员的决策。
建模的实质是：对现实的简化；通过将问题分割成一系列可以解决的、较小的问题来解决复杂问题。
3、建模的四原则是：（1）认真选择模型；（2）每个模型可以有多种表达方式；（3）最好的模型总是能够切合实际；（4）孤立的模型是不完整的。
4、面向对象＝对象＋类＋继承＋通信。
继承是指子类可以自动拥有父类的全部属性与操作；使得父类和子类之间能够共享数据和方法。
继承简化了对现实世界的描述，定义子类时不必重复定义那些在父类中已经定义过的属性与操作。
而只需专注于自己特有的属性与操作。
有了继承机制，软件的可复用性得到提高。
多态是指同一操作作用于不同的对象，可以有不同的解释，产生不同的执行结果。
通常通过派生类重载基类中的同名函数来实现。
分为：编译时的多态性和运行时的多态性。
5、面向对象的程序设计语言有：基于Smalltalk的语言；基于C的语言；基于LISP的语言；基于Pascal的语言。
6、面向对象分析的基本原则：抽象原则；分类原则；聚合原则；关联原则；消息通信原则。
7、面象对象分析的层次共有：主题层；类与对象层；结构层；属性层；服务层。
在设计期间主要扩充4个组成部分：人机交互子系统部分、问题域子系统部分、任务管理子系统部分、数据管理子系统部分。
8、Rstional Rose的主界面由标题栏、菜单栏、工具栏、工作区和状态栏组成。
默认的工作区由左侧的浏览器和文档区，右侧的编辑区和下方的日志记录组成。
9、Rational Rose中有4个视图：（1）用例视图：只关注系统功能的高层形状，不关注系统的具体实现方法；（2）逻辑视图：关注系统如何实现用例中提出的功能，提供系统的详细图形，描述组件之间如何关联。
1.基于构件的软件开发的优势是什么？基于构件的软件将软件开发的重点从程序编写转移到了基于已有构件的组装，更快地构造系统，减轻用来支持和升级大型系统所需要的维护负担，从而降低了软件开发的费用2.尝试用自己的语言介绍Kruchten的“4+1”模型。
Kruchten 提出了一个"4+1"视图模型，从5个不同的视角包括包括逻辑试图、进程视图、物理视图、开发视图、场景视图来描述软件体系结构。
每一个视图只关心系统的一个侧面，5个试图结合在一起才能反映系统的软件体系结构的全部内容。
3.在希赛公司的一个财务管理系统，财务部要客户提供…………4.不同的体系结构风格具有各自的特点、优劣和用途。
试对管道-过滤器风格、事件驱动风格、分层系统、C2风格和基于消息总线的风格进行分析比较。
P52-56(1)管道和过滤器特点：@使得软构件具有良好的隐蔽性和高内聚、低耦合的特点；@允许设计者将整个系统的输入输出行为看成是多个过滤器的行为的简单合成；@支持软件重用。
只要提供适合在两个过滤器之间传送的数据，任何两个过滤器都可被连接起来；@系统维护和增强系统性能简单。
新的过滤器可以添加到现有系统中来；旧的可以被改进的过滤器替换掉；@允许对一些如吞吐量、死锁等属性的分析；@支持并行执行。
每个过滤器是作为一个单独的任务完成，因此可与其它任务并行执行缺点：①通常导致进程成为批处理的结构。
②不适合处理交互的应用。
③因为在数据传输上没有通用的标准，每个过滤器都增加了解析和合成数据的工作，这样就导致了系统性能下降，并增加了编写过滤器的复杂性。
（2）（3）分层系统体系结构有以下优点：第一，支持基于抽象程度递增的系统设计。
这允许设计者可以将一个复杂系统设计按递增的步骤进行分解。
第二，支持功能增强。
因为每层至多和与之相邻的上层和下层交互，所以，改变某层的功能最多只会影响与之相邻的其它两层。
第三，支持重用。
与抽象数据类型一样，只要对相邻层提供同样的接口，每层可以有很多不同的可相互替代的实现方法。
构件：构件是指语义完整、语法正确和有可重用价值的单位软件，是软件重用过程中可以明确辨识的系统；结构上，它是语义描述、通讯接口和实现代码的复合体。
构件管理：1构件描述2构件分类与构件库组织：关键字分类法刻面分类法（青鸟）超文本组织方法（基本单位是结点）3人员及权限管理构件重用步骤：检索与提取构件（检索方法同上3种加其他）理解与评价构件修改构件（实参）构件组装（功能数据面向对象）软件体系结构：软件体系结构为软件系统提供了一个结构、行为和属性的高级抽象，由构成系统的元素的描述、这些元素的相互作用、指导元素集成的模式以及这些模式的约束组成。
软件体系结构不仅指定了系统的组织结构和拓扑结构，并且显示了系统需求和构成系统的元素之间的对应关系，提供了一些设计决策的基本原理。
软件体系结构的意义：体系结构是风险承担者进行交流的手段体系结构是早期设计决策的体现软件体系结构是可传递和可重用的模型软件体系结构建模的种类：结构模型框架模型动态模型过程模型功能模型4+1”视图模型从5个不同的视角包括逻辑视图、进程视图、物理视图、开发视图和场景视图来描述软件体系结构。
逻辑视图主要支持系统的功能需求，即系统提供给最终用户的服务。
开发视图也称模块视图，主要侧重于软件模块的组织和管理。
进程视图侧重于系统的运行特性，主要关注一些非功能性的需求。
物理视图主要考虑如何把软件映射到硬件上，它通常要考虑到系统性能、规模、可靠性等。
场景可以看作是那些重要系统活动的抽象，它使四个视图有机联系起来，从某种意义上说场景是最重要的需求抽象。
软件体系结构风格是描述某一特定应用领域中系统组织方式的惯用模式。
体系结构风格反映了领域中众多系统所共有的结构和语义特性经典的体系结构风格数据流风格：批处理序列；管道/过滤器。
调用/返回风格：主程序/子程序；面向对象风格；层次结构。
独立构件风格：进程通讯；事件系统。
虚拟机风格：解释器；基于规则的系统。
仓库风格：数据库系统；超文本系统；黑板系统。
研究生课程教学大纲《软件体系结构》《Software Architecture》36 学时； 2 学分一、课程简介本课程是硕士研究生专业基础课程之一。
软件体系结构（也称软件架构）的理论与实践近几年已经形成成熟的体系，成为软件工程中的一个新的及独立的领域，在大型复杂软件系统的开发过程中起着越来越重要的作用。
软件体系结构主要介绍软件体系结构和中间件的基本概念，使学生对软件体系结构有比较深入的了解。
通过学习，使得学生在软件工程思想的基础上，更进一步掌握软件分析和软件开发的方法和思想，并能在实际中应用。
在完成本课程后，使学生能够掌握软件架构的原理, 方法及技巧，了解常见的架构模式以及它们在企业应用，能够对软件架构进行分析，撰写软件架构文档。
完成本课程的学员可以在实际工作中胜任软件设计师及初级软件架构师的工作。
二、预修课程及适用专业预修课程：无适用专业：计算机科学与技术，计算机技术、软件工程、信息安全三、课程内容及学时分配本课程分为三部分内容。
第一部分将在软件工程基本原理基础上，讨论软件架构及软件架构师在软件工程中的作用，分析软件架构所要解决的软件工程中的问题，以及软件架构师应当具备的知识及技能体系。
第二部分以架构设计的过程为主线，有序展开相应的方法论与实践：如何从需求向架构设计过渡、概念性架构设计、细化架构设计。
并强调非功能需求设计的方法与设计思想。
第三部分介绍常见的架构模式以及它们在企业应用，设计模式如何合理用于架构设计实践，如何设计Framework。
第一章引言1.1 软件体系结构的概念1.2 软件的工程规范1.3 软件体系结构概况第二章体系结构模式2.1 体系结构模式2.2 管道和滤波器2.3 数据抽象和面向对象2.4 基于事件与隐含调用2.5 层次系统2.6 存储库2.7 中断2.8 过程控制2.9 其它类似结构2.10 不同种类的体系结构（多机系统）第三章用例研究3.1 文本中的关键字3.2 仪表化软件3.3 移动机器人3.4 巡回控制3.5 混合系统第四章共享信息系统4.1 共享信息系统4.2 数据库集成4.3 集成式软件开发环境4.4 集成构件设计4.5 共享信息系统的体系结构4.6 一些结论第五章软件体系结构设计5.1 用户界面体系结构5.2 限制设计空间第六章形式模式和规范6.1 体系结构形式化价值6.2 规范系统的形式化体系结构6.3 形式化体系结构模式6.4 形式化体系结构设计空间第七章软件体系结构的分析与测试7.1 体系结构的可靠性建模7.2 软件体系结构的可靠性风险分析7.3 基于体系结构描述的软件测试方法第八章软件体系结构评估8.1 体系结构评估概述8.2 软件体系结构评估的主要方式8.3 ATAM评估方法8.4 SAAM评估方法学时分配计划四、教学方法及要求教学方式：本课程强调及兼顾理论体系的体系性及技术题材的实用性。
软件体系结构◇软件体系结构概论◇软件体系结构建模◇软件体系结构风格◇软件体系结构描述◇动态软件体系结构◇Web服务体系结构◇基于体系结构的软件开发◇软件体系结构的分析与测试◇软件体系结构评估◇软件产品线体系结构软件危机的表现◎软件成本日益增长◎开发进度难以控制◎软件质量差◎软件维护困难软件危机的原因◎用户需求不明确◎缺乏正确的理论指导◎软件规模越来越大◎软件复杂度越来越高◎构件的定义构件是指语义完整、语法正确和有可重用价值的单位软件，是软件重用过程中可以明确辨识的系统；结构上，它是语义描述、通讯接口和实现代码的复合体。
构件模型的三个主要流派OMG（Object Management Group，对象管理集团）的CORBA（Common Object Request Broker Architecture，通用对象请求代理结构）Sun的EJB（Enterprise Java Bean）Microsoft的DCOM（Distributed Component Object Model，分布式构件对象模型）。
构件获取1.从现有构件中获得符合要求的构件，直接使用或作适应性修改，得到可重用的构件；2. 通过遗留工程，将具有潜在重用价值的构件提取出来，得到可重用的构件；3. 从市场上购买现成的商业构件，即COTS（Commercial Off-The-Shell）构件；4. 开发新的符合要求的构件。
构件管理◎构件描述◎构件分类与组织◎人员及权限管理构件描述构件模型是对构件本质的抽象描述，主要是为构件的制作与构件的重用提供依据；构件分类与组织◇关键字分类法◇刻面分类法◇超文本组织方法人员及权限管理一般来讲，构件库系统可包括五类用户，即注册用户、公共用户、构件提交者、一般系统管理员和超级系统管理员。
构件重用◎检索与提取构件◎理解与评价构件◎修改构件◎构件组装构件重用理解与评价构件◇构件的功能与行为◇相关的领域知识◇可适应性约束条件与例外情形◇可以预见的修改部分及修改方法构件组装◇基于功能的组装技术◇基于数据的组装技术◇面向对象的组装技术软件体系结构的定义软件体系结构为软件系统提供了一个结构、行为和属性的高级抽象，由构成系统的元素的描述、这些元素的相互作用、指导元素集成的模式以及这些模式的约束组成。
软件体系结构建模的种类
软件体系结构建模的种类包括以下几种：
1. 静态建模：通过建立模块、组件、类和接口的关系图来描述系统的静态结构，可以使用UML类图或模块图进行建模。
2. 动态建模：通过建立状态转换图、活动图或时序图来描述系统的行为和交互过程，可以描述系统的运行时行为，演示系统在不同情况下的工作流程，以及对象之间的交互等。
3. 逻辑建模：用于描述系统的逻辑结构和功能模块之间的关系，以及数据流、控制流和数据存储等的交互关系，可以使用数据流图、控制流图或业务过程图进行建模。
4. 物理建模：用于描述系统的物理结构，包括硬件设备、网络连接和部署方式等，可以使用物理架构图或部署图进行建模。
5. 构件建模：用于描述系统的构件、模块或服务之间的关系和依赖，以及它们的接口和交互方式，可以使用构件图或组件图进行建模。
6. 性能建模：用于描述系统的性能需求和约束，包括响应时间、吞吐量和资源利用等，可以使用性能模型或性能图进行建模。
7. 安全建模：用于描述系统的安全需求和安全策略，包括访问控制、身份认证和数据保护等，可以使用安全模型或安全图进行建模。
这些建模方法可以根据具体需求和项目特点选择和组合使用。
浅谈软件体系结构评估技术软件体系结构评估技术是指对软件体系结构进行分析和评估的一系列技术手段和方法。
软件体系结构评估旨在验证和评估软件体系结构的质量特征，如可维护性、可扩展性、安全性等，以确保软件体系结构的合理性和可靠性。
本文将从软件体系结构评估的重要性、评估的目标和方法以及常用的评估技术进行介绍和探讨。
首先，软件体系结构评估的重要性不言而喻。
软件体系结构是软件系统的基础和骨架，它决定了软件系统的结构和行为。
一个良好的软件体系结构能够提高软件系统的可管理性、可维护性和可扩展性，从而降低软件开发和维护的成本。
而一个不合理或糟糕的软件体系结构则可能导致软件质量的下降、性能的降低甚至无法满足需求。
因此，对软件体系结构进行评估能够发现潜在问题、提前预防风险，并为软件开发人员提供合理的决策依据。
其次，软件体系结构评估的目标是确保软件体系结构的质量特征满足系统需求和预期目标。
具体来说，软件体系结构评估的目标主要包括以下几个方面：1.验证和评估软件体系结构的功能需求是否得到满足；2.评估软件体系结构的质量特征，如性能、可靠性、可维护性等；3.发现和评估软件体系结构的潜在问题和风险；4.提供合理的决策依据，如软件体系结构的改进、优化或重构。
为了实现这些目标，软件体系结构评估需要采用一系列的评估技术。
在软件体系结构评估中，常用的技术包括静态分析、动态分析和模型驱动技术。
静态分析是通过分析软件源代码、设计文档和其他相关文档，发现和评估软件体系结构的问题。
静态分析的技术包括代码检查、代码审查、重构和模式识别等。
代码检查是通过对源代码进行分析和检测，发现代码中的问题和错误；代码审查是通过对软件设计文档和源代码的评审，发现设计和实现的问题；重构是通过对软件体系结构的改进和重构，改善软件体系结构的质量特征；模式识别是通过对软件体系结构的分析和比较，识别和应用已有的软件体系结构模式，以提高软件体系结构的质量和可维护性。
动态分析是通过运行时分析和测试，评估软件体系结构的性能和可靠性。
软件学报ISSN 1000-9825, CODEN RUXUEW E-mail: jos@Journal of Software,2013,24(8):1731−1745 [doi: 10.3724/SP.J.1001.2013.04360] +86-10-62562563 ©中国科学院软件研究所版权所有. Tel/Fax:∗运行时软件体系结构的建模与维护宋晖1,2, 黄罡1,2, 武义涵1,2, Franck CHAUVEL1,2, 孙艳春1,2, 邵维忠1,2, 梅宏1,21(高可信软件技术教育部重点实验室(北京大学),北京 100871)2(北京大学信息科学技术学院,北京 100871)通讯作者: 黄罡, E-mail: hg@, /~huanggang摘要: 运行时体系结构是系统运行时刻的一个动态、结构化的抽象,描述系统当前的组成成分、各成分的状态和配置以及不同成分之间的关系.运行时体系结构与目标系统间具有动态的因果关联,即系统的变化及时体现在体系结构上,而对体系结构的修改及时影响当前系统.运行时体系结构允许开发者以读写体系结构的方式实现系统的监测和调整,是体系结构层次系统动态适应与在线演化的基础.构造运行时体系结构的关键是针对不同的目标系统和体系结构风格实现合适的基础设施,以维护二者之间的因果关联.由于目标系统和体系结构的多样性以及因果关联维护逻辑的复杂性,这一构造过程往往过于繁琐、易错、难以复用和维护.提出一种模型驱动的运行时体系结构构造方法.开发者只需针对目标系统、体系结构以及两者之间的关系分别进行建模,根据这些模型,支撑框架自动构造合法而高效的运行时体系结构基础设施.基于MOF和QVT标准建模语言定义了一组运行时体系结构建模语言,并基于通用的模型与系统间同步技术实现了相应的支撑框架.一系列实例研究表明,该方法具有广泛的适用性,并显著提高了运行时体系结构构造过程的效率与可复用性.关键词: 运行时体系结构;模型驱动软件工程;领域特定建模;运行时维护与演化中图法分类号: TP311文献标识码: A中文引用格式: 宋晖,黄罡,武义涵,Chauvel F,孙艳春,邵维忠,梅宏.运行时软件体系结构的建模与维护.软件学报, 2013,24(8):1731−1745./1000-9825/4360.htm英文引用格式: Song H, Huang G, Wu YH, Chauvel F, Sun YC, Shao WZ, Mei H. Modeling and maintaining runtime softwarearchitectures. Ruan Jian Xue Bao/Journal of Software, 2013,24(8):1731−1745 (in Chinese)./1000-9825/4360.htmModeling and Maintaining Runtime Software ArchitecturesSONG Hui1,2, HUANG Gang1,2, WU Yi-Han1,2, Franck CHAUVEL1,2, SUN Yan-Chun1,2,SHAO Wei-Zhong1,2, MEI Hong1,21(Key Laboratory of High Confidence Software Technologies (Peking University), Beijing 100871, China)2(School of Electronic Engineering and Computer Science, Peking University, Beijing 100871, China)Corresponding author: HUANG Gang, E-mail: hg@, /~huanggangAbstract: Runtime software architecture is a dynamic and structural abstract of the running system, which describes the elements ofcurrent system, the state of these elements, and the relation between them. Runtime architecture has a causal connection with the runningsystem, in order for system administrators to monitor and control the system through reading and editing the architecture. The key toconstruct a runtime architecture is to develop the infrastructure between the target architecture and system. This is done to maintain thecausal connection between them. However, because of the diversity of target systems and architectures, and the complexity of the causalconnection maintaining logic between them, the development of such infrastructures is tedious, error-prone, and hard to reuse or evolve.∗基金项目: 国家自然科学基金(60933003, 91118004, 61222203); 国家重点基础研究发展计划(973)(2009CB320703); 国家高技术研究发展计划(863)(2012AA011207); 新世纪优秀人才支持计划(NCET-09-0178)收稿时间:2011-07-24; 定稿时间: 2012-09-131732 Journal of Software软件学报 V ol.24, No.8, August 2013This paper presents a model-driven approach to constructing runtime architectures. Developers describe the target system, the architecture, and the relation between them as declarative models, and the supporting framework automatically generates the runtime architecture infrastructures. The research designs the runtime architecture modeling language based on the extension of the standard MOF and QVT languages, and implements the supporting framework based on a set of general synchronization techniques between the system and architecture. A set of case studies illustrate that this approach applies to a wide range of systems and architectures and improves the efficiency and reusability of the construction of runtime models.Key words: runtime architecture; model-driven engineering (MDE); domain specific modeling; runtime maintenance and evolution近年来,随着软件应用领域的不断扩展以及云计算、服务计算、物联网等新的计算范型的出现,软件的运行方式逐渐由一次性的任务执行转变为长时间不停机提供服务,运行阶段在整个软件生命周期中的重要性越来越高.同时,随着软件运行平台逐步走向动态和开放,软件在长时间的运行过程中需要面对自身、运行环境、甚至用户需求的不断变化,这些变化都要求系统本身或者系统管理人员能够随时了解系统当前的运行状况,并及时通过对系统参数的重配置或对系统结构的调整等方式做出合适的响应,以维护系统的稳定、高效与安全[1].本文将系统运行时刻的监测、演化、重配置等工作统称为系统运行时管理[2].运行时软件体系结构是控制运行时系统复杂性、辅助系统运行时管理的有效途径[3].作为系统运行时刻的动态描述,运行时体系结构刻画了系统当前时刻的构成元素、各元素内部的属性以及元素之间的关系.运行时体系结构与目标系统之间具有“因果关联”,即系统发生变化时,体系结构随之改变;而体系结构被修改后,系统也将随之改变[4].这种动态的因果关联保证了系统管理者可以通过读写体系结构中的元素、属性以及连接关系,实现对目标系统的监测和调整.运行时体系结构抽象了系统的运行时数据,并以符合管理视角的方式对这些数据进行组织,同时对外提供简单、一致的操作方式.现阶段,运行时体系结构已经广泛用于企业计算、桌面应用、移动计算等不同类型的系统上,用以支持监测、维护、重配置、自适应等不同类型的运行时管理工作.这些研究工作的基础是针对不同的目标系统和不同的运行时管理方式开发合适的运行时体系结构基础设施(infrastructure)[5],以维护体系结构和目标系统之间的因果关联.具体而言,该基础设施通过系统底层管理能力获取系统当前状态,并据此更新上层的体系结构;而当体系结构被修改后,该基础设施根据具体的修改推导出合适的系统变化,并通过系统的底层管理能力将变化作用到当前的系统中去.现有的工作大多采用硬编码的方式构造运行时体系结构.开发者根据管理方式确定运行时体系结构的组织形式,根据系统管理能力确定系统支持的数据类型,最后编码实现二者之间的因果关联维护逻辑.尽管一些研究工作尝试提供开发框架支持上述过程中部分工作的自动化和复用,仍然有大量工作依赖于开发者的手工编码.这种构造方式过程繁琐,难以复用,构造后的运行时体系结构难以使用,影响了运行时体系结构的应用普及和更深入的研究.首先,在开发运行时体系结构基础设施的过程中,需要考虑系统底层管理能力调用、体系结构元素的表示以及二者之间因果关联维护等复杂问题,手工实现这些功能的编码量非常大,也容易出错.特别是对于因果关联的维护而言,由于系统和体系结构间具有异构性,系统变化和体系结构修改间可能存在冲突以及系统修改可能存在副作用等复杂情况的存在,如何正确而有效地实现二者之间的同步问题更为复杂.其次,在手工编码的运行时体系结构基础设施中,各种功能的代码交织在一起,难以理解、维护和复用.最后,由于对运行时体系结构及其与底层系统间的关系没有清晰的定义,管理者往往难以正确理解和有效使用运行时体系结构,特别地,由于不同的开发者对于因果关联缺乏一致、严格的定义,而具体运行时体系结构基础设施的因果关联维护逻辑隐藏在实现代码中,由此可能导致管理者错误理解运行时体系结构的行为,并最终导致不恰当的管理操作.模型驱动的开发方法(model-driven engineering)是提高开发效率、可维护性以及正确性的重要手段[6].近年来,模型驱动开发中的重要分支——领域特定建模(domain-specific modeling)——更是越来越受到开发者的重视[7].领域特定建模的核心思想是,针对特定类型的开发问题(即领域)设计一套有效的建模语言,开发者利用该语言,通过高层建模的方式描述针对具体的问题的解决方案,与建模语言配套的支撑框架通过模型转换、代码生成、运行时配置等方式自动化地实现开发者描述的解决方案.本文提出一种模型驱动的运行时体系结构构造方法.遵循领域特定建模的思想,开发者使用运行时体系结宋晖等:运行时软件体系结构的建模与维护1733构建模语言声明式地定义目标系统的管理能力、体系结构中的元素类型以及二者之间的关系.根据开发者提供的模型,相应的支撑框架自动生成合适的运行时体系结构基础设施.在系统运行过程中,该基础设施利用系统底层管理能力维护符合开发者描述的运行时体系结构,并根据开发者提供的系统与体系结构间的关系维护二者间的因果关联.实验结果表明,该方法广泛适用于不同类型的目标系统和体系结构,有效地提高了运行时体系结构构造过程的效率.本文的主要贡献在于:1) 一套基于MOF(meta-object facility)系列标准的运行时体系结构建模语言;2) 一组通用的体系结构与系统间因果关联维护机制及其正确性描述;3) 完整的运行时体系结构支撑框架,用于自动生成运行时体系结构基础设施.本文第1节介绍运行时体系结构的基本概念与相关工作.第2节和第3节分别介绍运行时体系结构的建模与自动生成.第4节和第5节介绍支撑框架的实现以及实例研究.第6节总结全文并讨论下一步的工作设想.1 运行时体系结构研究工作概述运行时体系结构是近年来软件体系结构领域的研究热点,并已逐渐成为运行时演化、系统重配置、系统自适应等运行时管理工作的重要辅助手段.运行时体系结构的研究始于Oreizy等人利用体系结构支持运行时系统维护的工作[5].他们将运行时刻的系统描述为C2风格的层次化体系结构,其中,构件代表当前系统中的功能处理模块,连接子代表模块间的通信.体系结构对外提供构件和连接子的增删以及连接子的重置等操作.体系结构和运行时系统间的基础设施保证二者之间实时的一致性,以便系统维护人员可以通过体系结构了解系统当前的结构和配置,并通过体系结构上的增删构件、重置连接子等操作实时地替换系统的功能模块或改变模块间的通信方式.Garlan等人将运行时系统描述为符合客户-服务器风格,携带性能与配置等属性的体系结构,并提供一种简单的体系结构操作语言给开发者编写自适应规则.这些规则定义了当全局或局部的性能属性满足某个特定的条件时,执行一组特定的系统重配置操作[8].Floch等人提出的MADAM方法进一步将这种命令式的自适应改进为声明式[9],在传统的运行时体系结构上,MADAM允许开发者为构件定义其属性之间的关联关系,同时允许开发者规定一组针对性能属性的全局的效用函数.在系统运行时过程中,运行时体系结构基础设施首先根据系统当前的状态更新体系结构以及性能属性的值.然后,效用函数计算器将当前的属性值分别代入一组预定义的体系结构变体中,分别根据构件间属性值的关联计算全局的属性,并在其基础上计算效用函数的值,随后选取使得效用函数值最大的体系结构变体.最后,体系结构基础设施比较所选体系结构变体与当前体系结构之间的区别,执行体系结构重配置.运行时平台的研究者和开发者利用运行时体系结构作为平台对外提供管理能力的接口.Blair等人提出了反射式中间件的概念,即,将中间件平台内部的部分状态和结构以可控的方式暴露给管理者[10].他们实现的反射式中间件OpenORM和OpenCOM均以体系结构的形式组织反射后的信息.在其后续工作中,Joolia等人利用ACME语言描述OpenCOM的运行时体系结构,以支持利用ACME附带的编辑工具和脚本语言进行图形化或自动化的系统重配置[11];而Giene工作进一步将反射信息抽象为特定领域的体系结构[12],通过代码生成的方式解决体系结构和系统数据间的异构性问题.国内南京大学[13]和北京大学[4]的学者也分别在SOA平台和JEE应用服务器上构造了运行时体系结构框架,用于支持自适应、在线演化等操作.随着相关研究的深入,运行时体系结构也开始获得工业上的应用,著名的开源集成开发环境Eclipse在最新的版本中将其整个图形界面描述为运行时体系结构,以支持可视化地动态配置系统界面[14].早期的运行时体系结构研究者均选择针对目标系统和应用方式重新实现特定的运行时体系结构基础设施,其中涉及到的系统读写、体系结构构造以及因果关联维护等逻辑均以硬编码的方式实现.这种实现方式会带来开发过程繁琐、难以复用和维护以及构造出的运行时体系结构语义不明确等问题,影响了运行时体系结构研究的推广和应用.为了解决这一问题,一些开发者尝试提供通用的运行时体系结构支撑框架.Rainbow为运行时体系结构基础设施定义了一个通用的、构件化的结构,以便面向类似系统或体系结构风格的基础设施之间可以复用某些组成部分[8].JADE框架给出了一个基于Fractal构件模型的运行时体系结构生成框架[15].开发者使用Fractal体系结构描述语言为特定系统中存在的构件和连接子类型进行建模后,JADE自动生成符合Fractal1734 Journal of Software 软件学报 V ol.24, No.8, August 2013构件模型标准的代码框架,在开发者补充了实际的系统操作逻辑后,这组代码可以在运行时刻自动为目标系统维护一个符合用户定义的Fractal 格式体系结构.现阶段,使用JADE 框架时开发者仍需要大量的代码编写工作以实现模型与系统间的同步,并且该框架目前只支持符合Fractal 标准的体系结构.MoDisco 项目提供了一个基于MOF 标准的运行时体系结构自动化构造框架[16],开发者使用MOF 元建模语言定制遗产系统所能提供的数据的元模型,MoDisco 生成相应的代码框架去读写该遗产系统,并将数据保存为符合MOF 标准的格式.该工作仍然要求用户在生成框架的基础上编写大量的同步代码,并且其支持的运行时体系结构是单向的.2 模型驱动的运行时体系结构构造方法本文提出一种模型驱动的运行时体系结构构造方法.遵循领域特定建模的思想,我们提供一组面向运行时体系结构的领域特定建模语言,支持开发者在一个较高的抽象层次声明式地为其所需的运行时体系结构进行建模.根据开发者提供的模型,我们的框架自动化地生成相应的运行时体系结构基础设施.本节通过一个简单的运行时体系结构示例,概要介绍该方法的构造过程与支撑框架.2.1 C2-JO 2nAS 运行时体系结构示例JO 2nAS 是一个开源的JEE 应用服务器[17],其上的应用由一组EJB 、Web 模块、数据源等格式的构件组成,一个应用中的构件可以增加、删除和替换,构件间的关系可以重置,构件内部对外暴露一些与状态、配置相关的属性,其中一些允许修改.JO 2nAS 仅提供了运行时管理的能力.在实际管理一个应用时,开发者需要编写大量的代码去调用JO 2nAS 的管理API,或者通过Web 或命令行形式的管理控制台逐一执行每一个系统读写操作.这种管理方式由于存在抽象层次低、缺乏全局的视图和一致性校验等缺点,管理过程繁琐,易出错.另一方面, Oreizy 等人提出的C2风格的运行时体系结构通过将系统的功能模块及其连接关系抽象为构件和连接子,提供层次化的全局视图以及高层的批处理脚本语言,为以用户界面为中心的软件系统的运行时管理提供了有效的支持[8].因此,为JO 2nAS 提供管理支持的可行途径之一是为其构造C2风格的运行时体系结构.图1展示了C2-JO 2nAS 运行时体系结构的一个实例.当前的目标系统是一个部署了Java Pet Store(JPS)应用的JO 2nAS 系统[18],宽矩形图元为C2定义的构件,代表JPS 中当前已部署的部分功能模块,包括EJB 、数据源、Web 模块等,窄矩形图元代表连接子.构件间以连接子为分割,形成层次化结构,最顶层负责数据存储,中间两层负责存储数据的获取以及业务相关的数据处理,最后一层构件负责Web 层次的数据表示.图中虚线框展示了该运行时体系结构如何支持可视化的系统管理:管理人员首先通过体系结构了解当前JPS 系统内部有哪些功能模块、模块当前的状态及模块之间的关联.如需为JPS 添加新的功能,管理人员只需直接在图中添加新的构件和连接子图元,指定构件对应的EJB 和Web 模块的文件地址.这一运行时体系结构的核心是一个特定于JO 2nAS 目标系统和C2体系结构风格的运行时体系结构基础设施.该基础设施一方面收集当前系统中存在的EJB 、数据源等元素以及元素的属性和元素间的关系,并据此更新体系结构;另一方面识别出体系结构上新增的构件,并根据构件的属性及其与其他构件之间的关系计算出合适的EJB 部署以及重配置等系统操作.Fig.1 C2-Styled runtime architecture for JO 2nAS application图1 C2风格JO 2nAS 应用运行时体系结构示例//localhost/petstore HSQL1UserEJ Customers CatalogEJB SignOnEJB ItemArtist ProductArtist //localhost/res宋晖等:运行时软件体系结构的建模与维护17352.2 模型驱动的运行时体系结构构造过程概述本文提出一种模型驱动的运行时体系结构构造方法,开发者对目标系统(例如JO2nAS)和运行时体系结构(例如C2)分别进行建模,相应的支撑框架自动生成所需的运行时体系结构基础设施.构造过程如图2所示.Fig.2 Overview of the model-driven construction of runtime architectures, and its modeling languages图2 模型驱动的运行时体系结构构造过程与建模语言概览建模过程包括系统建模和体系结构建模两个方面.系统建模过程描述目标系统对外提供的可管理信息的类型,例如EJB,Web模块等,以及如何使用系统底层的管理能力(例如JO2nAS提供的JMX管理接口)获取和修改不同类型的信息.这两部分的建模结果分别称为系统模型(system model)和访问模型(access model).体系结构建模定义体系结构中的元素类型(例如构件、连接子)以及体系结构元素与系统元素之间的关系,其建模结果分别称为体系结构模型和关系模型.我们提供了一组特定的建模语言来辅助开发者创建和维护这些模型.本文第3节将具体介绍这组建模语言以及为建模过程提供的辅助的自动化支持.根据用户提供的模型,通用的支撑框架自动生成合适的运行时体系结构基础设施,为目标系统提供符合建模定义的运行时体系结构.按照关注点分离的原则,我们将运行时体系结构分为内生体系结构和抽象体系结构两类:内生体系结构是系统模型的实例,按照系统自身的结构描述系统状态,但提供标准的模型读写方式对其进行操作.构造内生运行时体系结构的关注点在于屏蔽系统底层的管理操作,我们以代码生成的方式构造系统-体系结构同步器,实现底层管理操作的屏蔽;另一方面,抽象运行时体系结构是体系结构模型的实例,因此与系统本身和内生体系结构之间是异构的关系,在内生体系结构基础上构造抽象体系结构的关键在于异构模型间的同步.我们提供了通用的同步机制,根据两个体系结构模型和二者间的关联模型作为输入进行配置,可以获得特定系统的体系结构同步器.本文第4节具体介绍运行时体系结构基础设施的基本原理以及生成技术.本文介绍的运行时体系结构构造方法和框架符合OMG(Object Management Group)组织规定的MOF系列标准[19],因此,我们提供的建模语言均为MOF系列语言或其扩充,作为最终结果的运行时体系结构符合MOF标准规定的对象格式.1736Journal of Software 软件学报 V ol.24, No.8, August 20133 运行时体系结构建模运行时体系结构建模的目的是描述不同运行时体系结构之间的变化性,包括系统管理能力及其调用方式、体系结构元素类型及其与系统数据间的关系.我们定义了一组建模语言来帮助用户为这些信息进行建模.图3给出了这组建模语言的概览,所有建模语言均扩展或直接复用自MOF 系列标准中规定的MOF 元建模语言以及QVT-Operational 与QVT-Relational 两种标准的模型转换语言[20].Fig.3 Modeling languages for runtime architectures图3 运行时体系结构建模语言3.1 系统建模在系统建模过程中,开发者需要描述目标系统可管理数据的类型以及不同类型数据的获取和修改方式.我们称前者为系统模型,称后者为访问模型,并分别提供系统元模型和访问描述语言作为这两种模型的建模语言.我们通过扩展MOF 元建模语言定义系统元模型,如图3所示.其中,虚线以上的部分为MOF 核心元模型(EMOF)中定义的元素.限于篇幅,我们省略了这些元素内部的细节.内生系统体系结构由一组SysElement 构成,作为标准的MOF 元素,SysElement 继承自MOF 中定义的TypedElement,但携带一个额外的core 属性,用于记录该元素对应的系统数据的地址.此外,SysElement 还提供一组操作以判断其是否对应某个具体的系统数据(xIs)、获取和修改相关的子数据(xGet,xSet,xAdd,xDelete)以及创建和删除系统数据(xCreate,xDelete).每个SysElement 都有一个特定的类型,由SysClass 描述.系统体系结构的建模过程就是定义体系系结构中所有元素可能符合的类型,即定义一组特定的SysClass,SysClass 内部的属性和不同SysClass 之间的关联.因此,对系统进行建模时,只需使用SysClass,SysAttribute 和SysAssociation 这3个概念.SysClass 继承自MOF 中的Class,但开发者需要额外指定底层的系统数据的类型,由于我们现在只支持Java 语言的系统API,因此该类型为一个Java 类.同时,每个系统元模型包含一个根类,作为系统操作的起点.一个SysClass 可以携带若干属性(SysAttribute)和关联(SysAssociation).这两个概念均继承自MOF 中的属性(property),但区别在于:关联的目标类型一定是系统元模型中定义的SysClass,而属性的类型可以是任意数据类型.定义属性时需要额外指定该属性对应的系统数据的类型,即相应的系统API 调用的返回类型,这一类型和属性自身的类型并不一定一致,例如一个整数类型的属性,其对应的系统API 可能仅返回一个描述该数值的字符串.图4给出了使用该元模型描述的JO 2nAS 系统模型的示例.我们定义了一个根类型MBeanServer,包括一个属性,用来指定目标JO 2nAS 服务器的地址.从每个服务器中,我们可以获取3种类型的系统元素,分别是数据源(JDBCDataSource)、EJB 以及Web 模块(WebModule).对于每个类型的元素,我们可以获取名字(name)、文件地址(path 或filepath)等属性.对于数据源,我们还可以获得最大连接数(maxConn)和当前连接数(currConn)等配置和状态.EJB 和数据源之间有ref 关联,描述二者间的数据依赖.系统模型仅描述了系统对外提供什么类型的数据,但不同系统,甚至同一个系统中不同类型的数据,其访问。
