286.软件体系结构研究展望

 

软件体系结构研究新方向

21世纪软件技术展望
1.开放源代码
下一世纪的操做系统将继承如今好的操做系统的主要优势，变成开放的和进化的。在操做系统开放以后，系统软件产业将主要集中在软件环境平台和工具的研究开发上。可视化编程环境与工具、办公套件、家庭套件、学习套件等将会有很大的空间。

21世纪软件技术展望
2.跨平台
使得一次写好的应用软件在各类不一样硬件系统上均可以运行、使得已经设计好的程序模块被有效地重复利用。
目前跨平台这一设想尚未彻底有效地被实现，相信21世纪第一个10年必定能够完成。固然，如何解决非Java语言软件的跨平台问题仍然是一个难题。

21世纪软件技术展望
3.软件工业化
随着软构件的规范化和实用化，计算机软件生产的工业化程度会慢慢提升，软件发展的速度也会慢慢加快。估计到21世纪的第一个10年结束的时候，软件的工业化程度应该达到20世纪90年代中期计算机硬件的工业化程度。

21世纪软件技术展望
四、友好界面
多媒体技术、语音识别与合成技术、手写体文字的识别、天然语言理解与机器翻译技术、图像处理与图形学技术、用户图形界面技术、人工智能技术等等都是解决软件系统友好性的关键技术。

21世纪软件技术展望
5.基于网络的应用软件
利用了WEB浏览技术、多媒体技术和网络信息管理系统等综合技术而构成的网络应用软件（例如电子商务）将是从此软件业发展的最大舞台。

纲要
21世纪软件技术展望
软件体系结构研究新方向

软件体系结构研究新方向
IEEE 1471标准
基于软件体系结构的软件工程
基于体系结构的软件开发方法
基于体系结构的软件组装
基于体系结构的软件测试方法
面向服务体系结构（Service-Oriented Architecture）
柔性软件体系结构
自适应的柔性软件体系结构
移动环境下的软件体系结构
自修复系统
支持代码移动的体系结构
动态软件体系结构的描述

IEEE 1471标准
1.基本原则
每一个系统具备一个体系结构，但一个体系结构不是一个系统；
体系结构与体系结构描述不是同一件事；
体系结构标准、描述、及开发过程能够不一样，而且能够单独地进行研究；
体系结构描述自己是多看法的；
把一个对象的整体概念从其详述中分离开是撰写体系结构标准的一个有效方法。

IEEE 1471标准
2.体系结构定义
体如今各组成部分、它们相互关系及与环境的关系、和指导设计和演变的原理之中的一个系统的基本结构。

IEEE 1471标准
3.组成部分
对关键术语的定义，如体系结构描述、结构性视图与体系结构性视点；
对体系结构与体系结构描述在概念上的分离促进了描述体系结构标准（与蓝图标准相相似）和构筑系统标准（与建筑规范或城市规划法规相相似）的创建；
用于描述一个系统体系结构的内容要求。
IEEE 1471标准
4.体系结构描述要求
一个体系结构描述必须规定系统的用户，肯定他们体系结构的要点；
一个体系结构描述必须被编入一个或多个系统的体系结构视图中 ；
一个体系结构描述必须为制定关键的结构性决策提供基本原则 。
软件体系结构研究新方向
IEEE 1471标准
基于软件体系结构的软件工程
基于体系结构的软件开发方法
基于体系结构的软件组装
基于体系结构的软件测试方法
面向服务体系结构（Service-Oriented Architecture）
柔性软件体系结构
自适应的柔性软件体系结构
移动环境下的软件体系结构
自修复系统
支持代码移动的体系结构
动态软件体系结构的描述

基于体系结构的软件开发方法
ACPP
——以体系结构为中心的软件项目计划
ABDP
——基于软件体系结构的开发过程
ABC
——基于体系结构、面向构件的软件开发方法

体系结构的软件开发方法
体系结构的软件开发方法
体系结构的软件开发方法
软件体系结构研究新方向
IEEE 1471标准
基于软件体系结构的软件工程
基于体系结构的软件开发方法
基于体系结构的软件组装
基于体系结构的软件测试方法
面向服务体系结构（Service-Oriented Architecture）
柔性软件体系结构
自适应的柔性软件体系结构
移动环境下的软件体系结构
自修复系统
支持代码移动的体系结构
动态软件体系结构的描述

基于体系结构的软件组装
软件体系结构研究新方向
IEEE 1471标准
基于软件体系结构的软件工程
基于体系结构的软件开发方法
基于体系结构的软件组装
基于体系结构的软件测试方法
面向服务体系结构（Service-Oriented Architecture）
柔性软件体系结构
自适应的柔性软件体系结构
移动环境下的软件体系结构
自修复系统
支持代码移动的体系结构
动态软件体系结构的描述

基于体系结构的软件测试方法
体系结构形式化验证
多组态软件体系结构测试

基于体系结构的软件测试方法

基于有穷状态进程的形式化验证
基于时态逻辑的形式化验证
基于进程演算的形式化验证
基于Petri网的形式化验证

基于体系结构的软件测试方法
基于体系结构的软件测试方法
参与交互的构件是否能达到系统的目标
系统的完备性和效率
系统扩展的潜能
构件接口的一致性
构件之间链接的机制
构件行为的顺序
临界资源的争夺

软件体系结构研究新方向
IEEE 1471标准
基于软件体系结构的软件工程
基于体系结构的软件开发方法
基于体系结构的软件组装
基于体系结构的软件测试方法
面向服务体系结构（Service-Oriented Architecture）
柔性软件体系结构
自适应的柔性软件体系结构
移动环境下的软件体系结构
自修复系统
支持代码移动的体系结构
动态软件体系结构的描述

面向服务的体系结构SOA
三位一体的职责构成SOA
SOA应用示例
SOA特性
基于标准的互操做性
在SOA当中，接口、通信协议、工做流、协做和发布都是由一整套国际标准所定义，包括XML, SOAP, WSDL, UDDI, HTTP,CPP, ebXML, bSOA, BPEL, FERA, OWL-S等，从而保证不一样平台的系统可以无阻碍的交流
基于发现的动态组装
在SOA中的系统所须要的服务均经过运行时发现，运行时加载的方式工做
基于策略的动态管理和总控协做
SOA的各个服务的运行都由策略（Policy）进行控制，策略的制定、监测、执行均可在运行时内完成。SOA实行总控式协做，即由一个中心控制节点负责控制和调度分布在网络各处的服务

SOA分类标准
结构（Structure）
应用程序的结构是静态(S)仍是动态(D)
动态重组能力（Runtime re-composition capability)
能够在运行时进行重组(R) 不能够进行重组(N)
容错能力（Fault Tolerant Capability）
具备容错的骨干通信机制(FB)，具备容错的控制服务(FC)，不具备容错能力(FN)
软件工程支持（System Engineering Support）
是否具备系统支持的模型监测、数据收集、部署、代码自动生成、策略实施、一致性检查等机制。有用(SY)表示，无用(SN)表示
由此获得一个四元组
{Structure, Re-composition, Fault-tolerance, System-engineering}
对各类SOA进行分类

SOA类别及其进化
Customer Centric SOA
常规SOA模式
服务提供者向服务代理注册开发出来的服务，由应用程序构建者来寻找须要的服务
CCSOA模式
在传统SOA的基础上，应用程序构建者也能够发布应用程序模板，服务提供者能够根据模板的须要开发新的服务
Customer Centric SOA（续）
Customer Centric SOA（续）
上图的步骤为：
应用程序构建者编写应用程序模版，模板内包含工做流信息、须要服务规格信息等
应用程序模版在服务代理的库中进行注册并发布
一个订阅了应用程序模版库的服务提供者收到有新模版到达的通知，因而查询这个新模版
本体和分类技术能够辅助进行被提供模版和目标模版之间的自动匹配
在查询中，服务代理返回给服务提供者关于应用程序模版的详细信息
服务提供者依据模版开发新的服务，并提交到服务代理。服务代理依据模版中的信息对新服务进行校验和评估
一旦评估经过，服务代理通知应用程序构建者有可用的新服务
应用程序构建者评估和测试新的服务
一旦经过测试，应用程序构建者就将应用程序模版和新服务绑定，生成能够运行的应用系统

商业SOA平台
IBM基于WebShpere的SOA Foundation Architecture
软件体系结构研究新方向
IEEE 1471标准
基于软件体系结构的软件工程
基于体系结构的软件开发方法
基于体系结构的软件组装
基于体系结构的软件测试方法
面向服务体系结构（Service-Oriented Architecture）
柔性软件体系结构
自适应的柔性软件体系结构
移动环境下的软件体系结构
自修复系统
支持代码移动的体系结构
动态软件体系结构的描述

柔性软件体系结构
柔性软件体系结构定义
柔性软件体系结构的行为
柔性软件体系结构的应用领域
软件体系结构研究新方向
IEEE 1471标准
基于软件体系结构的软件工程
基于体系结构的软件开发方法
基于体系结构的软件组装
基于体系结构的软件测试方法
面向服务体系结构（Service-Oriented Architecture）
柔性软件体系结构
自适应的柔性软件体系结构
移动环境下的软件体系结构
自修复系统
支持代码移动的体系结构
动态软件体系结构的描述

自适应软件体系结构
自适应软件体系结构是根据操做环境的变化而变化的体系结构
外界的变化包括用户输入、硬件设备输入、传感器信号、以及程序指令等
自适应软件体系结构须要解决的问题
在什么条件下系统发生改变
自适应软件体系结构应具备开放性质仍是封闭性质
须要实现什么样的自适应程度
如何演算从而评估变化后带来的收益是否大于变化自己的成本
变化的频繁程度如何
自适应变化须要的原始信息有哪些

自适应软件体系结构
自适应的基本结构
Monitor监控外界的变化
Adapt负责调整系统模型
Control负责将外界变化演算出模型变化，并做出变化决策
移动环境的自适应柔性软件体系结构
为什么移动环境须要动态自适应
移动环境下设备每每须要连续工做，对自身进行改变必须在运行时下进行
移动设备经受的操做环境的改变与固定的计算设备相比要频繁的多
使用移动设备的用户的需求也在不断改变
自适应体系结构示例：Rainbow
软件体系结构研究新方向
IEEE 1471标准
基于软件体系结构的软件工程
基于体系结构的软件开发方法
基于体系结构的软件组装
基于体系结构的软件测试方法
面向服务体系结构（Service-Oriented Architecture）
柔性软件体系结构
自适应的柔性软件体系结构
移动环境下的软件体系结构
自修复系统
支持代码移动的体系结构
动态软件体系结构的描述

移动环境应用实例
User Context
来自用户及环境的改变
System Context
来自系统自己的改变
Adaptation Middleware
负责将外界的变化映射到体系结构模型库中的备选模型
Architecture Model
储备的预先设计好的体系结构模型，是改变的基础
Adaptable Application
实际被应用的可动态改变的系统
为什么使用体系结构的方法
基于编程语言的方法
使用条件表达式
使用参数
使用异常
缺点
将软件行为和自行应的过程混杂起来
当引入新的适应机制式时须要修改大量代码，形成扩展性底下
结论
采用移动中间件来具体负责适应行为
移动中间件
移动中间件特色
足够轻量使其能够运行在资源受限的手持设备上
支持异步通信，使移动设备能够用较短期周期性访问网络，用以节省能源
能够感知环境的变化、例如自身状态、位置、能够得到的服务等
移动中间件所做出的推理必须简单有效，即推理获得的改变决策必须使系统有较大的收益

移动中间件
中间件能够为解决分布是系统的基本通信和管理问题，使开发者专一于业务流程
在移动环境下，动态服务和位置发现，从而动态的调总体系结构的形态是移动中间件的核心思想
移动中间件实例MADAM
使用MADAM构建的系统
移动中间件的运行方式——可变属性
绑定属性实例
绑定属性实例（续）
移动柔性软件体系结构的发展
统一的、通用的体系结构模型和环境模型表示方法
如何更好的描述体系结构模型这个变化的基础
如何更好的描述环境模型这个变化的触发点
变化决策推理算法的设计范式
如何设计才能使推理算法能够在资源受限的设备上流畅运行，并保证其结果的有效性
用户干涉对推理算法的影响
例如调整某些属性的计算权重
软件体系结构研究新方向
IEEE 1471标准
基于软件体系结构的软件工程
基于体系结构的软件开发方法
基于体系结构的软件组装
基于体系结构的软件测试方法
面向服务体系结构（Service-Oriented Architecture）
柔性软件体系结构
自适应的柔性软件体系结构
移动环境下的软件体系结构
自修复系统
支持代码移动的体系结构
动态软件体系结构的描述

自修复系统
自修修复系统的分类
内部修复：修复代码和常规代码集成到普通代码当中
外部修复：修复代码单独做为一个构件存在于系统当中，与普通的代码互相隔离

自修复系统设计过程
体系结构设计
将系统分为两部分
体系结构管理器（AMR）和体系结构模型容器（AMC）
运行时环境（RE）和实际运行系统（RS）

自修复系统设计过程（续）
修复行为触发
运行时环境负责监控运行时系统的各个参数，并将数据发送给体系结构管理器
延迟信息
内存消耗
CPU占用
负载
系统异常
用户指令
修复行为
体系结构管理器负责分析收集的数据，并执行和校验体系结构的从新配置，并将决策的目标体系结构模型映射成运行时环境能够接受的操做集
运行时环境对运行系统执行实际的修复操做

体系结构管理器结构
Change Analyzer负责将监控的数据转换成修复策略
Reconfiguration Manager负责将修复策略变换体系结构图
Verification Manager负责用体系结构约束和体系结构风格对转换进行校验
Reconfiguration Manager将修复策略映射为运行时环境能够执行的指令输出
软件体系结构研究新方向
IEEE 1471标准
基于软件体系结构的软件工程
基于体系结构的软件开发方法
基于体系结构的软件组装
基于体系结构的软件测试方法
面向服务体系结构（Service-Oriented Architecture）
柔性软件体系结构
自适应的柔性软件体系结构
移动环境下的软件体系结构
自修复系统
支持代码移动的体系结构
动态软件体系结构的描述

支持代码移动的体系结构
代码移动
定义：能够动态改变代码和代码所在位置绑定的能力
优势
在须要传输大量数据的状况下，传输执行代码可能会更为快捷
使得代码具备自我决策的能力，在网络中自行传输

支持代码移动的基本结构
支持代码移动的运行环境结构
软件体系结构研究新方向
IEEE 1471标准
基于软件体系结构的软件工程
基于体系结构的软件开发方法
基于体系结构的软件组装
基于体系结构的软件测试方法
面向服务体系结构（Service-Oriented Architecture）
柔性软件体系结构
自适应的柔性软件体系结构
移动环境下的软件体系结构
自修复系统
支持代码移动的体系结构
动态软件体系结构的描述

动态软件体系结构的描述
SA一般是对系统的静态描述,若是须要改变体系结构则必须从新设计新的SA,这已不能适应如今愈来愈多的须要在运行时刻发生变化的系统的设计需求.则容许系统在执行过程当中修改其体系结构,修改过程一般也被称为运行时刻的演化(即在线演化)或动态性。主要的变化体如今如下几个方面：
动态软件体系结构的描述
结构:软件系统为适应当前的计算环境每每须要调整自身的结构,好比增长或删除构件、链接子,这将致使SA的拓扑结构发生显式的变化
行为:因为用户需求的变化或者系统自身QoS调节的须要,软件系统在运行过程当中会改变其行为,好比因为安全级别的提升更换加密算法;将http协议改成https协议,行为的变化每每是由构件或链接子的替换和重配置引发的
属性:已有的ADL大都支持对非功能属性(non functional properties)的规约和分析,好比对服务响应时间和吞吐量的要求等,在系统运行的过程当中这些要求可能发生改变,而这些变化又会进一步触发软件系统结构或行为的调整.属性的变化是驱动系统演化的主要缘由
风格:系统由一种体系结构风格演化成“衍生”的另一种风格。例如两层C/S结构衍生成多层C/S结构，或者衍生成B/S结构
动态体系结构描述的约束
一致性

体系结构规约与系统实现的一致性,运行时刻的修改应及时地反映到规约中,以保证规约不会过期
系统内部状态的一致性,正在修改的部分不该被其余用户或模块更改
系统行为的一致性,若“管道-过滤器”风格的结构中增长一个过滤器,则须要保证该过滤器的输入和输出与相连的管道的要求一致
体系结构风格的一致性,演化先后体系结构或者保持风格不变,或者演化为当前风格的“衍生”风格
完整性

系统的演化不能破坏SA规约中的约束
演化先后系统的状态不会丢失,不然系统将变得不“安全”,甚至不能正确运行.

 

动态体系结构描述的约束（续）
追溯性
传统的ADL采用逐步精化的方式将一个抽象层次很高的ADL规约逐步精化为具体的可直接实现的ADL规约，在精化的过程当中经过形式化的验证保证每一步精化都符合要求,知足可追溯性。
对于动态系统而言，追溯性除了须要知足静态设和净化阶段被知足，还须要被延伸到运行时刻，以保证系统的任何一次修改都会被验证，这样既有利于软件的维护，也为软件的进一步演化提供了可分析的依据。

动态体系结构描述语言D-ADL
将构件行为进行分类
计算行为：计算行为和动态行为.计算行为面向系统的商业逻辑,处理业务功能中的数据信息
动态行为：面向系统的预约义演化逻辑,使系统可以自适应演化,以体系结构元素为处理对象,如增删构件、创建新的链接等.
基于高阶π演算
全部描述行为均可在高阶π演算中找到对应表示
具备强有力的形式化基础，能够对软件体系结构行为做深刻的推理和规约
对高阶π演算进行扩充
对于某些不能使用高阶π演算方便表示的概念（间接能够表示）进行了扩充
提供了构件动态行为new、attach和detach的语法概念
动态体系结构描述语言D-ADL（续）
动态体系结构描述语言D-ADL（续）
动态体系结构描述语言D-ADL（续）
假设订购服务器(merchant)发生错误而死机或崩溃时,系统须要自动从新启动一个服务器实例,并将客户请求导向新的服务器,使服务不致中断.这种具备自动切换功能的商品订购系统的体系结构D-ADL描述以下:

compositecomponent TDynamicOrderSystem() {
port {environment: Tenvironment.}
. . .
choreographer {
via environment∧servermessage receive sign.
if sign = 0 then {
detach merchant∧port1 from cmlink∧portl-m1.detach merchant∧port2 from cmlink∧portl-m2.
delete merchant.
new merchant:Tmerchant().
attach merchant∧port1 to cmlink∧portl-m1.attach merchant∧port2 to cmlink∧portl-m2. }
replicate
}
}

动态体系结构描述语言D-ADL（续）
在接收到客户订购请求后,商家根据状况肯定是否可以知足订购请求的实际过程是订购服务器向仓储服务器查询是否有足够供货. 如下代码体现了系统“求精”的过程，添加了第三个端口Portm3
atomiccomponent Tmerchant() {
port {portm1:Tcaccess. portm2:Tmaccess.portm3:Tinquire}
computation {
choose {
{via portm1∧order receive orderdata. via portm3∧inquire send orderdata.
via portm3∧answer receive result.
if result then
{ unobservable. via portm1∧response send record(true,payment)}
else
{unobservable. via portm1∧response send record(false,0)}
},
{via portm2∧pay receive payment.unobservable.via portm2∧confirm send confirmation}}
replicate }
}
体系结构动态演化系统的设计
反射
反射(reflect)是指计算系统经过与自身状态和行为具备因果互联的系统自述，以描述、推理和操纵自身的能力
能够将体系结构包含在系统当中做为元数据，并对外提供访问接口，以实现对系统的体系结构进行运行时控制
体系结构在线演化的实施
体系结构在线演化的校验
使用类型系统检测一致性
将体系结构风格衍生路线设计为继承的类型体系，体系结构演化只能沿着继承路线向子类型前进
将构件接口类型化，在改变构件链接关系时要保证新的链接的类型一致
使用事务处理机制确保演化不被恶性中断
每次演化的一些列操做都在一个事务当中进行
演化发生错误时所有操做回滚
在分布式系统当中，事务可保证在线演化操做的在并行访问的状况下的正确性
链接器的形式化重用
链接器的形式化重用
经过重用旧有的、相对简单的链接器来获得新的、较为复杂的链接器，就能够得到一种增量式的链接器开发方法，从而提升软件开发的质量和效率
具备形式化基础（例如使用CSP）使得新的链接器定义能够进行形式化检测
链接器组合元操做
角色（Role）元操做
Substitute:角色的替代。能够实现用一个角色来充当另外一个已经定义的角色
ConcurrencyMerge:角色的并行合一。能够实现用一个角色来同时充当多个已经定义的角色，而且它“扮演”的多个角色之间应并行协调
AlternativeMerge:角色的选择合一。能够实现用一个角色来完成多个已经定义的角色的功能，而且在每一次完整的交互中该角色只能充当其中的某一个角色

链接器组合元操做（续）
Choice:该操做将两个或者多个粘结进程选择地组合起来。这种选择多是上述的不肯定性选择，也多是肯定的选择，即选择权在其所在环境的选择。若是它所规范的角色在某次完整的交互中想要参与的初始事件仅被某个子粘结进程所容许，那么组合粘结进程就选择该子粘结进程去承担该次交互的协调任务;不然，若是角色想要参与的初始事件为多个子粘结进程所容许，那么它就会任意选择其中的某个子粘结进程去承担这次交互的协调任务。
链接器组合元操做（续）
Interleave:该操做将两个或者多个粘结进程交错地组合起来。若是用这种组合获得的粘结进程去协调和约束某个角色的行为，那么该角色不管什么时候要想参与某一个事件，只需获得某个子粘结进程的容许便可。固然，若是此时有多个子粘结进程都容许该事件发生，那么组合粘结进程就会任意选择其中的某个子粘结进程去承担容许该事件发生的责任。

链接器组合元操做（续）
粘连（Glue）元操做
Parallel:该操做将两个或者多个粘结进程并行地组合起来。若是用这种组合获得的粘结进程去规范某个角色行为，那么该角色不管什么时候要想参与某一个事件，都必须获得各个子粘结进程的共同容许。
Decision:该操做将两个或者多个粘结进程不肯定性选择地组合起来。这里的不肯定性选择指的是:组合获得的粘结进程究竟选择哪个子粘结进程去规范角色的某一次完整的交互行为，由其自身来决定。
链接器组合元操做（续）
Follow:该操做将两个或者多个粘结进程顺序地组合起来。用这种组合获得的粘结进程依次用其子粘结进程去协调和约束其所规范的角色的行为，固然，后续的子粘结进程要想承担这种责任，必须知足前行的子粘结进程可以成功终止。
Interrupt:该操做将两个或者多个粘结进程顺序中断地组合起来。用这种组合获得的粘结进程能够随着后续子粘结进程初始事件的发生，用后续的子粘结进程去中断和接替前行的子粘结进程，并得到协调和约束角色的责任。
Lightning:该操做能够看做是Interrupt的一种特殊情形，它将两个粘结进程顺序中断地组合起来。但与Interrupt不一样的是，前行子粘结进程被中断并不取决于后续子粘结进程初始事件的发生，而是某个被定义的中断事件。为了表示这个特殊事件，咱们把它做为第3个参数引入到Lightning函数中。

链接器组合示例
链接器组合法性检测
检查1:链接器的每一个角色都是无死锁的
这是对链接器角色内部相容性的检测。因为组合链接器的每一个角色是在重用已有链接器的角色基础上获得的，所以，这种检查能够分为两种情形:若组合链接器的某个角色是经过替换或者选择合一获得的，那么对子链接器相应角色的检查结果仍然适用于组合链接器的这一角色；若组合链接器的某个角色是经过并行合一获得的，那么就必须从新检查。由于对于一个并行合一的角色进程，可能会出现这样的问题:在某个时候，虽然它的子角色都各自能参与某些事件，但它却不能参与任何一个事件。
检查2:链接器是无死锁的
这种相容性的检查是对链接器总体的检查。所以，检查1若是通不过，也会反映到检查2中。角色规范了充当其实例的组件预期要发生的行为，而粘结规范的是对这些行为的协调与约束。角色规范与粘结规范是否会出现矛盾，就须要用检查2来考察。

本学期课程到此结束

清华大学软件工程与管理学院