构件模型

构件模型（共6篇）

构件模型篇1

摘要：构件识别被认为是基于构件的软件开发过程中最重要的阶段之一。主要介绍如何根据构件特征和特征模型间的对应关系, 运用聚类算法从特征模型中识别出业务构件。首先, 给出特征模型的形式化定义, 然后给出基于特征的构件模型的形式化定义, 最后根据构件模型和特征模型的关系, 运用聚类算法从特征模型中识别出业务构件。

关键词：特征模型,业务构件,构件识别

基于构件的软件开发 (Component-BasedSoftwareDevelopment, CBSD) 被认为是解决企业信息系统重构的关键技术之一[1]。随着标准构件模型如CORBA, DCOM, EJB等的迅速发展和日益成熟, 基于构件的软件开发被广泛应用到企业信息系统的开发过程中。与传统的软件开发方法相比, 基于构件的软件开发主要侧重于获取可重用构件并且通过这些构件的组装满足应用系统的功能需求。在基于构件的软件开发中主要由两个阶段组成:业务构件的构造 (businesscomponentFabrication) 和应用系统的组装 (applicationsystem assembly) [2]。

业务构件的构造通常包含以下四步: (1) 领域分析和领域建模; (2) 业务构件识别; (3) 业务构件设计; (4) 业务构件实现。

领域分析和领域建模的主要目的是建立领域的业务模型。领域业务模型来自领域知识, 具有相对的稳定性, 但由于外部因素的影响, 领域知识也会逐渐变化和发展, 领域业务模型应该能够支持领域知识的这种演化, 所以现阶段的领域工程研究活动中, 大多采用特征来刻画业务模型的语义[3]。特征是从用户角度对系统的感知, 是从用户角度对系统的认识, 能够充分体现用户的需求, 且能体现系统具有的某种能力或特点。因此, 用特征模型来刻画领域业务模型是一种非常值得借鉴的方法。

业务构件识别阶段的主要任务是从企业的业务模型中识别出可重用的业务构件。

现主要研究如何根据构件和特征模型中特征间的关系, 运用聚类算法从特征模型中识别出业务构件。

1扩展特征模型的形式化定义

如上文介绍, 因为用特征模型来刻画领域业务模型是一种非常值得借鉴的方法, 因此本文也采用这种方法。但由于应用领域的业务过程的复杂性、多样性及流程性决定了每个领域的特征之间存在一定的偏序关系。现有的特征模型虽然对特征间常见的结构关系、配置依赖和运行依赖进行了总结和分析, 但无法对特征之间的偏序关系进行描述, 因此有必要对现有的特征模型进行扩展, 以描述这种偏序关系。

可以用一个五元组来描述本文扩展的特征模型:FM= (F, A, C, λA, λC) 。其中:

(1) F:特征模型中的特征集合。特征可定义为一个二元组F= (n, M) 。

■n为特征的名称。

■M={bop1, bop2, …, bopk}为特征所包含的业务操作集, 特征通过对外提供业务操作来完成相应的业务需求。M中的每个业务操作bopk (k=1, 2, …, m) 可以定义为bopk= (nk, tk, dk, Prebopk, Postbopk) 。其中:

●nk为业务操作的名称;

●tk为业务操作的类型, 业务操作通过具体的操作类型对底层的业务数据进行维护。tk∈{Insert, Update, Delete, Query};

●dk为业务操作所操作的业务表单;

●Prebopk为业务操作执行的前置条件;

●Postbopk为业务操作执行的后置条件;

●可以将业务操作执行的前置条件和后置条件, 称为事件。事件是驱动业务操作执行的动因。在业务过程中存在需求事件、通知事件和时间事件。需求事件由业务环境产生, 通常来自于人机接口, 并可被业务活动所接收;通知事件由业务活动产生, 它或者将事件的描述信息传递给环境, 或者进一步触发其他业务活动的执行;时间事件指在时间上触发的一个变更。特征间存在的偏序关系可以通过业务操作执行的前置条件和后置条件来反映。

(2) A:特征模型中的特征关联集合。主要存在两种关联关系:聚集和泛化。

(3) C:特征模型中的特征配置依赖约束集合, 包括必须 (mandatory) 、异或 (alternative) 、或 (or) 和可选 (optional) 四种, 配置依赖刻画了从领域工程到应用工程映射的时候, 特征被选取时应满足的约束条件。

(4) λA:表示集合F到集合A幂集的映射, 即:λA:F→P (A) , 其中P (A) 表示集合A的幂集, 并且满足

即对于任意一个特征, 可以和其它特征之间存在多种关联关系, 而对于任意一个特征关联, 至少牵涉到两个特征。

(5) λC:表示集合F到集合C幂集的映射, 即:λC:F※P (C) , 其中P (C) 表示集合C的幂集, 并且满足:

即对于任意一个特征, 可以存在多种约束表达, 而对于任意一个特征约束, 至少牵涉到两个特征。

由此可见, 现提出的扩展特征模型的概念实际上由两部分组成;一方面, 扩展特征模型通过对特征结构关系和配置依赖关系进行形式化定义和完善, 对特征模型进行了扩展, 构成了扩展特征模型的底层架构和基础;另一方面, 扩展特征模型通过对模型中的特征定义进行形式化描述, 引入了特征执行的操作、操作的业务表单、执行的前置条件及后置条件, 从而对特征模型进行了细化, 构成了特征模型的上层建筑。两者紧密结合, 实现了领域工程软件开发全生命周期阶段特征选取确定可复用框架之上的各类应用系统的快速定位和组装, 生成满足配置依赖关系和约束条件的应用系统。

2基于特征的构件模型

在领域分析和领域建模阶段, 用特征刻画了业务模型的语义, 为了在业务模型空间和构件空间建立明确的映射关系, 为能够从业务模型中识别出可重用业务构件, 继续用特征来刻画业务构件的语义。

定义1 (基于特征的构件模型) :一个业务构件定义了特定业务领域的一个特征子空间。基于特征的构件模型可以表示为C[cid, froot, F, D, C, PS, RS], 其中:

(1) cid为构件的唯一标识;

(2) froot为构件特征空间的根特征, 是构件所有其它特征的祖先特征;

(3) F为构件特征空间包含的除根特征外其它特征构成的集合;

(4) D为特征关联的集合;

(5) C为特征约束的集合。;

(6) PS为构件向外提供特征的集合;

(7) RS为构件从外界需求特征的集合;

(8) PS F, 且RS F。因为特征间存在偏序关系, 而构件的运行既需要从外界获取特征, 又需要向外界提供特征。所以, 通过特征间存在的偏序关系反映了构件间存在的偏序关系。

基于特征的构件模型还应满足以下约束条件:

(1) Fdescendant (froot) 。

(2) 对必有parent (f) RS。

(3) 构件模型中只有一个根特征, 如果在实际业务模型中, 存在多个根特征, 需要为这些根特征构造一个虚拟的父特征以使构件只有一个根特征。例如图1对领域特征分解中, 构件C2中包含了两个兄弟特征f2, f3都为根特征。为与定义一致, 构造一个虚拟特征vf作为f2, f3的虚拟父特征, 并将其作为C2的根特征。

3 基于相似度的构件识别算法

本节采用聚类的思想, 根据特征模型中各个特征间的依赖关系及约束关系, 从特征模型中识别出业务构件。该算法的基本思想是:找出当前特征模型中包含的最大关联集, 并将该集合中的所有特征映射为一个构件。

3.1 基于相似度的构件识别算法[4]

输入:领域特征模型FM, 样本点关联阈值Rmin

输出:构件集合C_set;

步骤:

Step 1:将特征模型中每个特征作为一个样本点, 并将这些样本点记为undefined。此时, 集合X中的每个样本点自成一类;

Step 2:确定任意两个样本点之间的关联值 (即相似程度) 的计算方法, 将样本点Xi与Xj之间的关联值记为Rij;

Step 3:计算n个样本点两两之间的关联值, 得样本点间的关联值矩阵D;

Step 4:选定一个合理的最小关联值Rmin, 将其作为将两个样本点放入一个聚集的判定依据;

Step 5:依据关联值矩阵D中每个单元的关联值Rij, 执行以下聚类过程:

■ (阈值) 如果Rij≥Rmin, 则将样本点Xi和样本点Xj放入一个聚集;

■ (传递性) 如果Xi和Xj属于一个聚集, 且Xj和Xk属于一个聚集, 那么将Xi, Xj, Xk放入一个聚集;

Step 6:最后, 将每个聚集中的所有样本点合在一起转换为一个业务构件内。

3.2 关联值计算公式的选择

通过分析基于相似度的构件识别算法, 知道该算法的关键在于样本点间的关联值的计算以及样本点间最小关联值Rmin的确定。

通过第二节介绍的扩展特征模型, 知道扩展特征模型中各个特征之间并不是独立存在的事物, 而是这些特征通过相互合作以完成领域系统或应用系统的功能需求, 因此, 除了要计算特征间的静态关联值以外, 还需要计算特征间应为约束关系存在的动态关联值。结合文献[2]究成果, 给出特征间关联值的计算公式如下。

① 特征间静态关联值

RSij=undefinedundefined

其中:

■ RSij表示特征 (样本点) fi和fj间的静态关联值, 且fi和fj为两个不相同的特征;

■ Uαi为二值变量:如果关联关系α包含了特征 (样本点) fi, 则Uαi设为1;如果关系α中不包含特征fi, 则Uαi设为0;

■ Uαj与Uαi的取值方法相同;

■ Wα为该关系α所占的权重, 根据关系α紧密程度设定:泛化关系Wα=5;聚集关联Wα=3;无关联, Wα=0。

② 特征间动态关联值

RDij=undefinedundefined

其中:

■ RDij表示特征 (样本点) fi和fj间的动态关联值, 且fi和fj为两个不相同的特征;

■ Vci为二值变量:如果约束关系c包含了特征 (样本点) fi, 则Vci设为1;如果约束关系c中不包含特征fj, 则Vci设为0;

■ Vcj与Vci的取值方法相同;

■ Wc为该约束关系c所占的权重, 根据关系c紧密程度设定:必须特征, Wc=1;可选特征, Wc=0;或约束, Wc=0;异或约束, Wc=-2。

③ 特征间关联值:

undefined

其中

■ Rij表示特征fi和fj间的关联值;RSij和RDij分别表示的是特征fi和fj间的静态关联值和动态关联值;

■ fi≠fj表示的是fi和fj为两个不相同的特征;

■ fi=fj表示的是fi和fj为两个相同的特征。

3.3 算法的时间复杂性分析

在进行算法时间复杂性分析之前, 设特征模型中特征的个数为n;特征模型中特征之间的关联关系个数为nα, 则nα≤n2;特征模型中特征之间的约束关系个数为nc, 则nc≤n2。

对该算法的时间复杂性分析如下:

① step 1的时间复杂性为O (1) ;

② step 2的时间复杂性为O (1) ;

③ step 3需要计算样本点间的静态关联值和动态关联值, 其复杂性分别为O (nα) 和O (nc) , 且step 3需要计算n2个样本点间的关联值, 所以其复杂性为undefined, 即undefined;

④ step 4的时间复杂性为O (1) ;

⑤ step 5的时间复杂性为O (n2) ;

综合起来, 整个算法的复杂性为undefined。

4 应用举例

设一个库存子系统的部分特征模型如图2所示。

下面开始构造特征间的关联矩阵。由于图2中包含的特征比较多, 本文仅列出以“入库”为根特征构造的特征关联矩阵, 如表1所示。

如果选择Rmin=6, 则以“入库”为根特征的特征子空间由表1可以得到以下3个构件。入库构件c1, 且F (c1) ={入库, 采购入库, 社会捐赠入库};记账构件c2, 且F (c2) ={记账};价格核算构件c3, 且F (c3) ={价格核算, 计划价格核算}。

如果根据Rmin识别出的构件不够理想, 可以根据实际情况, 重新为Rmin赋值, 以获取合适的构件。

5 结束语

运用聚类思想从领域的业务模型中识别出了可重用的业务构件。为了在领域的业务模型空间与构件空间之间建立明确的映射关系, 从而能够从业务模型中识别出构件。本文借鉴现阶段已被广泛接受的方法, 用特征来刻画业务模型和构件的语义, 通过特征建立二者之间明确的映射关系。

为了更好的刻画业务模型和构件的语义, 本文首先针对现有各种特征模型的不足, 提出了一个扩展的特征模型, 反映了特征间存在的偏序关系。然后, 又提出了一个基于特征的构件模型, 从而又实现了用特征刻画业务构件。最后, 用聚类的思想从领域的特征模型图中识别出业务构件, 并用实例说明了业务构件的识别过程。

参考文献

[1]Meng Fanchao, Zhan Dechen, Xu Xiaofei.Business component iden-tification of enterprise information system:a hierarchical clustering method.E-Business Engineering, 2005:473—480

[2]Jain H, Chalimeda N, Ivaturi N, et al.Business component identifi-cation—a formal approach.In:Proceedings of the5th IEEE Interna-tional Enterprise Distributed Object Computing Conference.Seattle:IEEE Computer Society Press, 2001:183—187

[3]胡燕, 崔华.基于特征领域模型的精确建模过程研究.理工大学学报, 2006;28 (5) :116—119

[4]徐玮, 尹宝林, 李昭原.企业信息系统业务构件设计研究.软件学报, 2003;14 (7) :1213—1220

构件模型篇2

1 建筑火灾中的火焰高度

火焰高度至结构构件表面的净距对火源面和构件表面之间的辐射传热有较大的影响。一般而言, 构件表面到火源面之间净距越小, 受到的火焰辐射传热越大。

现行相关规范中有关火焰高度的计算方法, 如表1所列公式 (1) ～ (5) 。

1.1 火焰高度计算式的比较

比较表1中各计算式发现, 将式 (4) 中Q的量纲换算成与式 (1) 相同的kW, 则式 (4) 与式 (1) 相同。将式 (2) 中Qc=0.7Q关系式代入式 (5) , 则式 (5) 与式 (2) 相同。由式 (1) 、式 (3) 和式 (5) 可得, 火焰高度主要由火源直径Df和火源热释放率Q确定, 而火源热释放率一般由undefined确定。其中, q为单位热释放率, kW/m2。

因此, 火源直径Df和单位热释放率q是影响火焰高度的关键参数。

1.2 影响火焰高度的参数分析

当火源直径Df分别取0.5、2.0、5.0 m时, 表1中不同计算式计算的火焰高度L随单位热释放率q的变化分别如图1～3所示。

比较图1～图3可得按式 (3) 计算的火焰高度基本比式 (1) 和式 (5) 的计算值小。并且, 对应不同的火源直径, 总存在一个单位热释放率的界限值q0, 当q

当已知火源直径, 且其单位热释放率q小于q0时, 式 (5) 的火焰高度计算值较式 (1) 大。当已知火源的单位热释放率q, 假定q=q0, 按图5可得对应的Df, 如果其火源直径大于图4中对应的Df值, 则式 (5) 火焰高度计算值较式 (1) 大。

文献中提出对于建筑火灾, 单位热释放率一般不大于500 kW/m2。给定单位热释放率为500 kW/m2, 按图4可得当火源直径Df>0.81 m, 式 (5) 的火焰高度计算值偏于安全。在大空间建筑火灾场景中, 火源直径一般都大于0.81 m。因此, 选用式 (5) 的火焰高度计算值是偏于安全的。

2 大空间建筑火灾的烟气温度计算

2.1 烟气层温度计算式的比较

假定地面面积A=500 m2, 空间高度H=9 m, Q=800 kW, 火灾类型为快速火, 比较CIBSE TM19、NFPA 92B、CECS200:2006中烟气层温度公式计算值, 如图5所示。

NFPA 92B和CIBSE TM19的烟气层温度计算式基于双区域模型, 当烟气层接近地面时 (距地面距离小于0.5 m) , 便不再符合双区域模型的假设, 在图5中, t>900 s后烟气层温度也偏高。烟气层高度下降接近地面所需时间远小于文献规定的构件最低耐火极限30 min, 故NFPA 92B和CIBSE TM19中烟气层温度计算式不适用于大空间建筑结构抗火研究。

图6所示EN1991-1-2:2002中大空间局部火灾 (Localised fires) 的烟气温度计算式仅预测没有侧限 (四周开放) 的空间, 其火源正上方高度为z处的羽流温度Tp, 没有考虑温度-时间历程和大空间建筑火灾温度场的非均匀性。

CECS200:2006中烟气温度计算是基于场模型的数值实验数据得到的拟合公式, 与大空间建筑火灾中温度分布吻合较好, 但是需要确定较多的待定系数, 不方便实际工程应用。

2.2 基于场模型的烟气温度简化公式

文献中提出的烟气层升温计算式 (6) 中的火源正上方烟气最高升温Tundefined与火源面至建筑空间顶面的垂直距离H、建筑空间顶面投影面积Asp以及火源功率Q有强相关性, 式 (6) 中其他参数说明见文献。

式中:T (x, z, t) 为对应于t时刻, 与火源面中心水平距离为x、垂直高度为z处的烟气温度, ℃。

如图7所示, Tundefined随Asp的增长而降低, 随Q的增长而升高。根据Tundefined随H、Asp和Q的系列变化曲线, 可拟合得到计算Tundefined的经验公式 (7) 。

将各影响参数计入式 (7) , 避免了式 (6) 中Tundefined需根据影响参数查表插值计算的繁琐。

式 (6) 中指数函数式1-0.8e-β t-0.2e0.1β t的系数β与火源功率和火源功率增长类型有关。火源功率增长类型虽然对于烟气升温速率影响较大, 但对烟气的最高升温值影响较小。因此, 可以偏安全地选择快速增长型Q=αt2为典型火灾类型, 取α=0.046 89, 可得达到火源功率Q所需时间undefined。如图8所示, 当火灾历程在undefined时段, 烟气最高升温Tundefined从0按undefined速率增长;当undefined时, Tundefined达到按式 (7) 确定的Tundefined值;当undefined后, Tundefined与火灾历程时间无关。

式 (6) 中的拟合系数η和μ均用于描述最高烟气温度Tundefined在距火源中心水平距离为x处的温度衰减程度, 为简化温度衰减函数ksm=ηs+ (1-ηs) exp (- (x-b) /μ) , 偏安全地取μ=7。其中, Ksm为距火源面中心水平距离为x处的建筑空间顶面烟气最高升温衰减系数 (无量纲) , 当x

经以上简化分析, 可得简化式 (8) 。

式中:ksm=ηs+ (1-ηs) exp (- (x-b) /7) ;Q按实际火灾场景确定, 难以确定时参见文献, WM; T (x, t) 为对应于t时刻, 与火源面中心水平距离为x处的建筑空间顶面的烟气温度, ℃。

考查式 (8) 精确性, 取Q=25 MW, 快速火, A=1 000 m2, H=12 m, 如图8所示简化公式 (8) 计算值偏于安全, 并满足工程实用要求。

3 结论

通过对火焰高度和烟气层温度计算方法的比较和简化, 可以得到以下结论:

(1) NFPA 92B火焰高度计算式 (1) 与建议计算式 (5) 之间存在一个单位热释放率界限q0, 当q≤q0时, 式 (5) 火焰高度计算值大于式 (1) , 在建筑火灾条件下建议计算式 (5) 火焰高度计算值偏于安全。

(2) 基于对式 (6) 的简化分析, 提出用于确定大空间建筑火灾中烟气温度增长历程的简化计算式 (8) , 该式既满足工程设计精度要求又方便实用。

参考文献

[1]程远平, 陈亮, 张孟君.火灾过程中羽流模型及其评价[J].火灾科学, 2002, 11 (3) :132-137.

[2]CECS 200:2006.建筑钢结构防火技术规范[S].北京:中国计划出版社, 2006.

[3]杜咏, 李国强.大空间建筑火灾中火焰辐射对无保护钢构件升温的影响[J].火灾科学, 2006, 15 (4) :189-199.

[4]NFPA92B.Guide for smoke management systems in malls, atriaand large area[S].

[5]TM19.Relationships for smoke control calculations, The Char-tered Institution of Building Services Engineers[S].

[6]EN1991-1-2:2002.Eurocode 1:Actions on structures-Part 1-2:General actions-Actions on structures exposed to fire[S].

[7]KLOTE HJ.Method of predicting smoke movement in atria withapplication to smoke management[S].

[8]杜咏, 李国强.大空间建筑火灾中烟气温度计算模型的比较[J].自然灾害学报, 2007, 16 (6) :100-104.

[9]建筑钢结构防火技术规范 (2008送审稿) [S].

构件模型篇3

关键词：Widget,本地扩展,构件技术,Web技术,编程模型

1 概述

进入互联网时代后,各种Web技术层出不穷,而Widget则以其个性化、小巧的特点占有一席之地。Widget是一种基于Web技术的小程序,以浏览器为运行平台,在PC电脑、手机屏幕、网页都有展现。目前,Widget的创新以及Widget的运营都是各个手机制造商、电信运营商全力开发的领域,而本文主要是以Widget本地扩展为起点,分析设计Widget编程模型。

在移动互联网时代,越来越多的手机网络应用融入到人们的生活。但由于移动网络相比于宽带网络稳定性的不足,基于网络的手机应用应该具有网络缓存能力。而频繁传输网络数据会对手机电量、资源的消耗产生较大影响,因此更应该避免持续大量的网络数据传输。这就要求Widget具备更强的本地能力来适应移动互联网的需求。

当然,由于本地能力依赖于系统平台的实现,其带来的负面影响是降低Widget的平台无关性和它的动态性。为了解决这个负面影响,本文提出了基于构件技术的本地扩展。构件技术建立在面向对象技术的基础之上,构件具有动态安装、卸载的特性,可以满足动态性的要求。而构件技术的代表,CAR构件(Component Assembly Runtime)、Java业界的OSGi框架都具有平台无关性。由此,本文提出了基于构件技术的Widget本地扩展模型。

2 Widget与构件技术概述

2.1 Widget简介

Widget来源于运行在苹果操作系统之上的称为“Konfabulator”小工具,在2004年之后迅速发展进入了一个新的时代。Widget是指一小块可以在任意一个基于HTML的Web页面上执行的代码,表现形式可能是视频、地图、新闻、小游戏等,主要代码形式是HTML、CSS、Java Script等。Widget具有小巧、形式多样和极具个性化的特点,并且十分易于制作,因而在互联网上迅速传播并广泛应用。无论是内容丰富的博客、热度持续升温的社交网站,还是原本静态的电脑桌面、小巧的手机屏幕,都有Widget的存在。

2.2 Widget编程模型

最初的程序都是基于单机开发,之后逐渐形成了C/S(客户端/服务器)的开发模式。在网络时代到来后,B/S(Browser/Server)开发模式因其简便的运行维护发展迅速。B/S相比于C/S模式,所有程序数据、程序逻辑都在服务器端,浏览器端只是负责界面显示,因而维护升级更为简单,成本更低。但B/S模式下服务器运行负荷较重,浏览器端不如C/S模式下的客户端反应迅速。

Widget是继C/S模型与B/S模型之后一种新的编程模型,兼具C/S与B/S的特点。一方面Widget是Web技术的一种,具有从网络动态下载、运行的能力,并且以浏览器作为运行环境,具备平台无关性,另一方面Widget作为桌面小程序的一员,具有本地能力及相互交互、组合的能力。

Widget编程模型是以浏览器作为界面展示平台,以Java Script为程序逻辑承担者,以本地扩展库为系统功能实现体,以Widge为程序运行单元,由一个或多个Widget协作构成整个程序的模型。

2.3 构件技术

为了解决不同软件开发商提供的构件模块(软件对象)可以相互操作使用,因而提出了构件技术。构件化技术建立在面向对象技术的基础之上,是完全面向对象的,提供了动态构造部件模块(运行中可以构造部件)的机制。构件在运行时动态加载,是可换的。CAR构件技术是面向构件编程的编程模型,它规定了一组构件间相互调用的标准,使得二进制构件能够自描述,能够在运行时动态链接。CAR构件基于Elastos中间件平台,具有平台无关性。

3 浏览器本地扩展技术

本小节对目前浏览器的本地扩展技术分类进行介绍,下一节将以浏览器本地扩展技术为基础提出Widget本地扩展模型的实现

目前浏览器的本地扩展技术主要有如下三种:

3.1 基于插件技术的扩展

即通过浏览器自身提供的插件功能来执行本地代码、实现本地功能,如IE的Active X技术、Webkit的Plugin功能,目前已通过此种方式实现了Java Script与CAR对象交互。

这种方式不需要更改浏览器代码,只需要基于现有的浏览器进行相应的插件开发,但在这种方式下,与Java Script交互有局限性,不利于本地功能与Java Script频繁的交互,并且加载插件会有额外的消耗。

3.2 基于对象注入的扩展

此种扩展方式的原理是浏览器本身将本地对象(如Java对象、C对象、Objective-C对象)注入在Java Script执行环境中,并封装其为Java Script对象以供Java Script进行调用。这种方式与JNI(Java Native Interface)有相似之处,因而也有称之为JSNI(Java Scrip Native Interface)。此种方式有广泛的应用,如Opera浏览器中的Widget引擎、Ophone中的JIL Widget引擎、各种浏览器的功能扩展(如Chrome的web下载页面,Mozilla的Web设置界面),以及Palm出品的Web OS中各种Web应用与本地服务的交互。这些扩展应用的共同之处是提供一个或多个Java Script内置对象来提供本地功能或浏览器功能的调用。

3.3 基于类注入的扩展

尽管基于对象注入的扩展有广泛的应用,但在这种扩展方式下Java Script对象与本地代码对象是调用者与被调用者的关系,而非对象间的交互关系。基于类注入的扩展可以提供给Java Script以实例化本地类的能力,促使建立跨语言的面向对象系统。

对象注入与类注入的区别是,对象注入也称实例注入,Java Script执行环境只能通过这一个对象执行其相应的方法,而类注入则可以让Java Script执行环境创建新的对象并调用。前者类似于简单的接口调用,而后者则是跨语言的对象级交互。

本文将在4.2节介绍基于对象注入的扩展技术的模型实现。

4 模型的设计与实现

4.1 模型的基本结构

模型实现的基本结构如图1。

Widget本地扩展模型中主要的四个模块是功能库层、桥接层、封装层以及扩展管理模块,其功能分别如下:

1)功能库层:本地功能的实现层。该层基于构件技术实现,由各种构件组成,如OSGi中的Bundle、CAR构件等。这些构件的安装卸载等功能由扩展管理模块进行管理。

2)桥接层:模型的中间层,也是扩展模型的关键,通过3.1节列举的三种方式,将功能库层的Java对象注册给浏览器或Java Script执行环境,供封装层调用。

3)封装层:通过对桥接层提供的API进行封装,提供给Widget开发者或Web应用程序开发者完善的JS库进行调用,使得在不同平台、不同桥接技术的基础上提供给开发者相同的调用接口库。

4)扩展管理模块:该模块负责Widget本地功能扩展的管理,包括权限管理、生命周期管理、构件管理。该模块不仅作为Widge扩展能力的管理者,也需要对于功能库中的构件进行管理,包括构件的安装、注册、运行、注入、卸载等。

4.2 模型的实现(基于Android平台)

这两年来发展最快的操作系统莫过于谷歌公司推出的Android手机操作系统,Android的开源使得开发者进行详细分析研究,而且Android系统在智能手机平台的占有率在日趋提高,因而本文在Android系统上实现Widget本地扩展模型模型。

4.2.1 桥接层实现

桥接层是模型实现的关键,在Android系统平台下,浏览器已具有基于对象注入的扩展能力,即可以将Java对象注入Java Scrip运行环境中,并提供一个对应的Java Script对象给Widget调用。

桥接的具体实现原理如图2。

图2描述的是Android系统中Web View中注册Java对象为JS对象的原理,其中JS对象是JSObject类的实例,Java对象通过Java Instance类的实例来表示。在浏览器运行过程中,当调用注册JS对象时,通过解析会执行JSObject类的属性instance的相应方法,进而通过Java虚拟机提供call JNIMethod ID()等方法实现Java代码的执行。

4.2.2 功能库层实现

功能库的实现基本思路与开发Java本地应用相同,通过调用系统平台提供SDK API获取本地功能。需要注意的是作为功能库的实现,需要提供一个Java实例对象或可实例化的类给模型引擎,引擎将此对象或类实例的对象注册给浏览器,进而实现桥接。其中在Android平台下,注册的Java对象只有公开的实例方法可供JS调用。方法的参数和返回值支持基本类型,包括int、long、boolean、String。

4.2.3 封装层的实现

通过封装层的引入,使得扩展模型可以向开发者提供完善的API库,而非受限于桥接层的实现方法不同而使得API库的接口不同。如JIL Widget的API定义本身包含File类型、Address Book Item类型等,若直接将桥接层的接口提供给Widget开发者,则开发者只能获得包括File信息或Address Book Item信息的字符串,而非Widget API定义的相应类型。通过封装层的引入,将桥接层返回的JSON字符串转化为相应的File类型或Address Book Item类型的JS对象,由此即可实现完善的API库。

4.2.4 扩展管理的实现

扩展管理模块在此实现中主要负责构件的运行、构件的注入。在Widget运行时将向扩展管理模块发送注入构件扩展的消息,扩展管理模块根据Widget的配置信息以及权限分配机制决定是否注入相关构件扩展,并将负责注入的构件的生命周期的管理。

4.3 模型的进一步实现

目前4.2节介绍的模型实现主要有两点还需要完善:一点是桥接层基于类注入扩展的实现;另一点是功能库层基于构件技术的完善实现。

4.3.1 基于类注入扩展的桥接层实现

参考文献2可知,已实现CAR构件以类注入的方式对浏览器进行扩展。而基于这种技术实现的桥接层可以使得Java Script运行环境与CAR构件运行环境通过跨语言对象的方式进行交互,而不是通过类似于JNI(Java本地接口)的方式进行简单的本地功能调用。

在基于类注入的扩展方式下,不仅仅是单一语言环境下是面向对象的,而且几个语言环境合并的整体也是面向对象的,这就可以极大地促进各种语言的相互影响,而不是语言之间相互孤立。

4.3.2 完善功能库的构件化实现

Widget是Web技术的一种体现,Widget自身也具有Web技术的动态性。Web网页原本就是从网站服务器动态获得的,因而将Web网页及其相关资源封装的Widget也具有这种运行时获取的动态性。而如果Widget依赖的本地扩展不具有这种动态性,Widge就会因此失去这一重要特性。

基于构件技术实现的功能就具有了这种动态性,构件的动态安装、运行、卸载提供了Widget本地扩展功能动态性的可能。若以某种确定的规则规定构件如何动态从网络获取,那么就可以保证Widget本地扩展与Widget具有一致的动态性,这也为以后与云计算技术进行融合打下基础。

基于目前实现的功能库以构件化的方式运行的基础上,要完善构件的动态获取、安装的能力。

5 应用

目前本文已完成基于Android平台的模型实现,并据此实现三个手机应用:Widget引擎、乐媒、手机导航,其中乐媒已在具体产品中应用。

在工程实际开发过程中,发现了如下几个问题:

1)采用Web技术作为程序的界面和主要逻辑承担者,可以加快程序开发进度。而且由于Web自身的平台无关性,使得依据本文的模型实现的程序跨平台更为容易。但由于不同平台下采用的本地扩展技术不同,使得桥接层可以复用的代码较少。

2)多种语言环境下的开发一方面要求系统设计人员对整个程序的功能有明确的划分,以便进行分模块的快速开发,另一方面要求开发人员在程序出错时能快速定位错误位置。

3)同时也遇到开发程序稳定性的问题。由于Java Script作为解释型语言,不需要编译,尽管这加快了开发进度,但需要更多的测试工作来发现程序运行时错误。因而在开发过程中,要求开发人员与测试人员具有更高的沟通效率,开发团队要形成快速的开发测试周期。

6 结束语

本文提出了基于构件技术的Widget本地扩展模型,并据此完成了该模型在具体工程的应用。基于Web技术进行本地程序开发,可以加快程序开发进度,并且依据本文提出的模型可以很好的将本地功能与程序逻辑分离开,便于进行跨平台的程序开发。另外,在模型应用于工程的过程中,也发现了目前模型的不足,包括模型实现的稳定性、模型对开发测试工作的影响以及功能库模块化的必要性,模型还可以进一步改进。本文提出的模型对开展基于Web技术的本地程序开发具有积极的意义。

参考文献

[1]Antero Taivalsaari,Tommi Mikkonen,Dan Ingalls,Krzysztof Palacz.Web Browser as an Application Platform[C].Proceedings of the200834th Euromicro Conference Software Engineering and Advanced Applications,2008(9):293-302.

[2]蒋章慨,陈榕.基于CAR构件的WebKit本地扩展策略[J].计算机应用,2009(S2).

[3]Elastos资料大全[Z].上海科泰世纪科技有限公司,2008.

[4]The Android Project[EB/OL].http://www.android.com/.

构件模型篇4

关键词：分布式系统,构件模型,SMP,OpenMP,线程绑定

0 引言

在松耦合的分布式系统中,应用对局部计算性能的需求不断提高(表现为对计算时延的敏感),因此将并行计算能力与分布式系统相结合是一个重要问题。所谓分布式系统是指一个系统的部件(包括计算机、传感器和执行机构等)处在不同的地理位置,但功能上合作的计算机系统[1]。从定义中可以看出,单纯的网络系统不是分布式系统,因为它没有任务上的分工合作机制。而任务的协同,要求有一定的时间约束。

在分布式系统中,当局部处理机执行的计算任务规模较大时,要求计算软件有较高的计算性能。目前,在一个处理器上集成多个计算内核比较普遍,称为对称多处理系统SMP(Symmetric Multi-Processor)。在SMP系统中,计算内核共享内存及数据总线,可以采用多线程并行计算获得更好的性能。

主要的操作系统都提供了多线程编程API,如Win32 Thread、Linux POXIS Thread等。但上述方法具有不可移植、编程繁琐的不足,限制了多线程技术的应用。而OpenMP技术具有增量并行的优点[2,3],即可以将一个串行程序代码逐步演化为并行程序代码。这使程序开发人员可以将并行程序编写划分为两个阶段:(1) 编写串行程序代码并调试;(2) 添加编译指导语句,逐步并行化原有程序并调试。这提高了并行程序的开发效率。

但是,已有的多线程模型没有考虑SMP系统中线程的无序迁移问题[3]。在操作系统的调度下,线程在多个内核之间频繁迁移会进行大量的数据移动操作,从而降低性能。本文针对该问题,在软件设计中提供了线程绑定的接口,能够改善多线程计算程序的执行效率。

相比于传统的分布式软件系统,本文将多线程并行计算技术与分布式松耦合环境相结合:SMP处理机的内部计算采用OpenMP多线程方式;网络上采用TCP/IP协议传输数据。并且,使用基于构件的软件工程方法CBSD(Component-based Software Development),提高了程序的可维护性和可重用性[4,5]。构件封装了程序的通信函数、配置逻辑和线程管理方法,从而提高系统对不同应用的适应性。通过构件组装,用户只需重新编写局部计算代码,缩短了开发时间。

1 OpenMP原理与线程绑定技术

OpenMP标准是一种SMP系统上的编程模型[2],它由编译指导、运行函数库和环境变量组成。这一规范简化了在SMP系统上创建多线程程序的开发过程。相比使用操作系统API来创建线程,OpenMP多线程有以下优点:

(1) 支持CPU内核数改变当处理器升级到更多核后,已编译的OpenMP软件不需要重编译,就可以根据系统环境变量动态生成适当数量的线程。

(2) 编程模型易用性高 OpenMP通过编译指导语句就可将串行代码并行化,减少了程序员工作量。例如可以将无递归for循环自动分解为多线程。

(3)程序具有可移植性使用OpenMP的多线程程序代码不需修改就可以在不同的操作系统上编译。

OpenMP的多线程程序的运行模型是:分叉与连接,在程序中局部的高计算负载代码段创建并行区。线程的分叉与连接是在并行区的首尾自动执行的,如图1所示。

首先,按照并发要素的不同,并行计算可以分为任务并行和数据并行,OpenMP支持这两种并发模型:

(1) 任务并行指一个程序可以分解为多个局部任务,且这些任务可以并发执行。在OpenMP中相应为并行分段模型:

在不同的section中,可以存在数据交换与协作执行,即线程同步与互斥关系。当使用barrier指导语句时,所有线程要在此处同步;而使用critical指导语句时,同时只能有一个线程进入[6]。

(2) 数据并行是指程序中所要计算的数据可以分解为多个数据块,并且这些数据块可以被独立地操作。在OpenMP中相应为并行循环(parallel for)模型:

这里需保证N阶for循环是非迭代的,即上一阶循环的结果不作为下一阶循环的输入。

其次,为了消除由于线程迁移而导致的性能降低,OpenMP线程绑定技术将线程固定在指定内核上运行。当前主要有两种方法实现线程绑定操作:环境变量方式和调用API方式。

(1) 主流编译器,如GCC,编译的OpenMP并行程序可以通过设置环境变量实现线程绑定。例如:

export GOMP_CPU_AFFINITY="1 3 5 7"

上述环境变量表示将四个线程绑定到CPU第1、3、5、7号内核上运行。

(2) 一些编译器,如Intel Compiler,支持使用线程绑定API,实现线程与内核的绑定。

在OpenMP程序中,可以使用kmp_set_affinity()函数来设置当前线程与内核core_id的绑定关系。本文使用这一方式,将在2.3节中详细说明。

2 构件模型的设计与实现

2.1 软件框架结构

本文提出的分布式构件模型是基于中间件设计的,中间件屏蔽了下层异构,并提供明确定义的接口,使分布式构件具有可移植性和简洁的内部结构。采用本构件实现的分布式系统具有如图2所示的分层结构。它包含三个主要部分:(1) 系统层,是基于网络的分布式的软硬件平台;(2)构件层,是可复用的分布式构件及其连接关系,实现数据处理逻辑;(3) 用户层,是完成用户数据的输入与显示的交互界面软件。

在构件层中,本文提出的组成分布式构件模型的三种基本构件为:计算单元(EU)、数据端口和连接子。在系统层中,OpenMP是并发计算中间件,为EU构件的设计提供了多线程并行计算能力。通信库的使用,使数据端口和连接子的设计与底层网络配置细节相隔离,如TCP、CORBA、COM等。

EU构件是最主要的基本构件,它负责计算任务的多线程执行与端口的管理等,以实现高性能的分布式计算。EU构件通过输入端口得到待处理数据,并通过输出端口将处理结果发送出去。端口为EU构件提供了输入输出缓冲区,并绑定对应具体网络的连接子。根据不同的分布式应用需求,可能需要在构件之间实现3种不同的通信方式:一对一、一对多或多对一。EU构件通过聚合多个端口,实现不同的通信拓扑结构。连接子封装了与网络硬件交互的通信代码,使通信与计算分离。这里的通信代码,可以使用TCP的socket API接口,或分布式中间件(如CORBA,DDS等)。

一个实际可部署的分布式构件的结构如图3所示,它由上述基本构件组合而成,称为复合构件。其中,EU构件包含多线程计算任务、线程管理和端口管理等功能属性。线程管理接口设定计算任务的线程数量,端口管理接口设定端口的添加与删除,并定义连接子间的连接关系。两个复合构件的输入连接子与输出连接子连接以实现数据传输,因此实际的分布式应用软件由多个复合构件组装而成。

一个复合构件的结构可以使用BNF范式进行描述,其中非终结符用斜体字加“< >”来表示,终结符用“[ ]”来表示:

<复合构件>::={<数据接口>, <计算单元>}

<数据接口>::={<输入端口集>, <输出端口集>}

<输入端口集>::={[输入端口1], [输入连接子1], …, [输入端口n], [输入连接子n]}

<输出端口集>::={[输出端口1], [输出连接子1], …, [输出端口n], [输出连接子n]}

<计算单元>::={[计算任务], [线程数]}

因此,基于本构件的分布式系统可以描述为:

<分布式系统>::={<构件实体集>, <构件关系集>}

<构件实体集>::={<复合构件1>, …, <复合构件n>}

<构件关系集>::={<构件连接1>, …, <构件连接n>}

<构件连接>::={[复合构件x的输出连接子a], [复合构件y的输入连接子b]}

2.2 分布式连接子的设计

通过构件化设计技术,将TCP通信代码封装,屏蔽了TCP的实现细节,具有很好的通用性。基于TCP的连接子与分布式中间件(如DDS、COM等)提供的复杂API相比,具有小巧易用的特点,并且避免了中间层故障而引起的系统崩溃。

连接子分为两类:输出连接子和输入连接子。这两类连接子与输出、输入端口相对应,并与相应端口直接交互。端口和连接子是连接关系。对应于TCP/IP协议,本文设计了相应的TCP连接子。

如图4所示,两类连接子connector_out类和connect_in类,都是connector类的实现并定义了数据收发的虚函数sendData()和recvData()。TCP连接子类继承于相应的父类,定义了私有的通信函数,并重写了父类的数据收发虚函数,实现了基于TCP的数据通信。

一对连接子在建立TCP连接时,使用一致的链路信息结构(link_info),其定义如下:

连接子实现TCP点对点通信的具体配置过程为:

(1) 数据发送方(conn_out_tcp)作为TCP通信中的服务端首先绑定本地IP地址(my_info.ip_addr)及IP端口(my_info.ip_port)。之后等待连接请求,并建立TCP连接。

(2) 数据接收方(conn_in_tcp)作为TCP通信中的客户端首先设定TCP连接目标的IP地址(my_info.ip_addr)即IP端口(my_info.ip_port)。然后发送连接请求,并返回套接字。

因此,建立通信要确定一致的链路信息,并告知一对连接子,其中ip_addr与发送方主机的IP地址一致。

2.3 OpenMP线程绑定的实现方法

在EU构件中,使用OpenMP实现线程到内核的绑定,以优化并行效率。在Intel Compiler中提供了对OpenMP标准的完整支持,并相应提供了一组线程绑定API。本文分析了有关API的实现方法,将其封装在计算构件(EUComp)类中。其具体代码为:

其中,函数参数me由kmp_create_affinity_mask(&me)初始化,用于储存当前线程设置的绑定信息。调用函数kmp_set_affinity_mask_proc(core, &me)可以建立指定的CPU内核core与变量me的对应关系。

bind()函数实现了SMP节点上的线程绑定方法,其调用位置在计算任务的OpenMP并行区中,由各个线程分别调用。在线程绑定实施之后,即可开始具体的计算工作。以并行for循环为例,其主要代码:

上述代码创建了4个计算线程,并将每个线程绑定到独立的内核运行。这一方法既充分利用了硬件资源、提高了并行度,又避免了线程无序迁移引起的性能下降。

3 应用实例与分析

在分布式系统的设计中,通常考虑处理机的计算性能和处理机间的网络通信时延。本实验设计了两个示例构件:(1) FFT构件,将512×1024个浮点FFT运算作为计算负载,对比了使用OpenMP线程绑定技术对计算性能的影响;(2) 数据源构件产生仿真数据,作为FFT构件的输入,以测试TCP连接子的数据传输性能。

实验的硬件平台是两台工作站通过千兆网络连接,Intel 4 cores 2.4GHz(支持HT超线程技术)、2G内存。软件平台为Linux 5.3 64bit和Intel Compiler 10.1及IPP函数库。其中,Intel IPP函数库提供了FFT计算函数。

在计算性能测试中,采用1、2、4、6、8个线程,分别进行有、无线程绑定的对比实验,共十组。每组实验执行5次取平均值。FFT构件中计算任务的主要代码如下:

从图5可以看出,在关闭线程绑定时,线程由1个增加到2个使计算并行度提高而计算时延减少。但当线程数继续增加时,由于线程的无序迁移和竞争资源的影响,导致计算时延显著增加。当线程数增加到8个时,计算时延达到了22ms(图中未标出)。这说明,在不使用线程绑定时,线程数的增加反而会使计算性能出现显著地下降。在开启线程绑定后,线程不迁移而使计算性能逐渐提高。也可以看出计算性能的提高与线程增加不呈线性关系,这是因为线程的管理开销也随之增大。当线程为8个时,线程管理开销过大而使性能略有下降。相比较而言,EU构件的线程绑定功能可以有效提高计算性能。

在网络性能测试中,两台处理机通过一个千兆交换机连接。使用四组不同大小的浮点数据块,通过TCP连接子在两台处理机间往返100次取平均值再除以2,测得单向通信时延,如图6所示。

可以看出随着数据块的增大,传输时延基本呈线性增加。通过计算,可以得出在不同的数据块大小时,网络的吞吐量基本为118.65MB/s,而千兆网络的理论峰值速率为125MB/s。可以看出,使用TCP连接子可以较好地利用网络带宽资源,能够满足分布式应用的需求。

4 结语

分布式系统因其松耦合的特点而得到了广泛的应用,本文使用CBSD方法设计了一种支持OpenMP线程绑定的分布式构件模型。在分析了OpenMP线程绑定原理的基础上,该构件模型实现了线程绑定控制接口,提高了EU构件的计算性能。使分布式软件也可以满足一般的高性能计算需求,通过构件组装方法开发应用程序使程序具有较好的适应性。本文给出了使用TCP套接字的连接子的设计方案,以及EU构件中线程绑定接口的实现方案。通过实验验证,线程绑定能够有效提高多线程程序的执行效率,构件的数据传输能力也满足应用需求。

参考文献

[1]Hagit A,Jennifer W.分布式计算[M].2版.北京:电子工业出版社,2008.

[2]李建江,舒继武,陈永健,等.一种基于动态并行区的OpenMP程序开发模式[J].计算机研究与发展,2006.43(3):496-502.

[3]徐磊,徐莹,张丹丹.多核构架下OpenMP多线程应用运行性能的研究[J].计算机工程与科学,2009,31(11):50-53,57.

[4]王晨,周颖,张德富.一种并行分布对象的互操作模型[J].软件学报,1999,10(8):861-867.

[5]王静,吴健.一种基于分布式对象技术的分布式监控系统设计[J].计算机应用与软件,2007,24(9):83-84,90.

[6]武汉大学多核构架与编程技术课程组.多核构架与编程技术[M].武汉:武汉大学出版社,2010.

构件模型篇5

近年来,承受平面内剪应力和正应力作用的钢筋混凝土薄膜元的空间桁架模型得到迅速的发展,并逐渐趋于成熟,能够表达构件荷载—变形关系的全过程。这种模型已经在钢筋混凝土结构受扭计算中得到广泛应用[1,2,3]。但是这种计算模型需要一套准确的材料本构关系来协调静力平衡方程和变形协调方程,计算模型中材料本构关系方程的正确与否,直接影响计算结果的精度。本文结合算例对材料本构关系的选择作了讨论,并给出本文推荐采用的结果。

1 计算模型中的材料本构关系方程

在以往的对受扭构件计算中,主要存在以下两方面的问题:

1)考虑到混凝土的主拉应力比主压应力小一个数量级,故认为构件开裂后受拉混凝土对承载力的贡献很小,忽略混凝土拉应力的影响。

2)钢筋。钢筋则假设为理想弹塑性,和裸钢筋的应力—应变关系一致,即:

当εs≤εy时,σs=Esεs;当εs>εy时,σs=fy。

众所周知,钢筋混凝土在开裂后的力学性能和素混凝土有很大的不同,素混凝土在充分开裂后,不能承受拉应力,而钢筋混凝土裂缝间的混凝土却由于受到钢筋的销栓作用仍然可以承受部分拉应力,虽然这种裂缝间混凝土受拉作用的贡献不大,但作者认为却不可以忽略。首先,受拉混凝土对钢筋混凝土结构的承载力影响不大,但却由于其存在使得构件的刚度较大,故在减小构件开裂后的变形上作用比较明显。如果混凝土的拉应力被忽略,那么单元的柔度和构件的变形将被高估;其次,构件中,裂缝间钢筋和混凝土是共同工作的,被混凝土包围了的钢筋的力学性能和裸钢筋有很大的不同,在混凝土开裂后,裂缝处的钢筋的应力较高,而裂缝间的钢筋应力相对要低,随着荷载的增加,裂缝处的钢筋达到了屈服应力,而裂缝间的钢筋应力由于受混凝土的加劲作用要小的多,并没有达到屈服应力。因此钢筋在屈服时的平均应力,称之为“平均屈服应力”,该值明显要小于裸钢筋的屈服应力,显然如果应用裸钢筋的应力—应变曲线(见图1),计算单元的屈服强度就会被高估。

因此本文作以下修正:

1)考虑受拉混凝土的影响(见图2)。采用受拉混凝土平均应力—应变的曲线方程为:

2)对钢筋的本构关系方程作了修订(见图3)。采用被混凝土加劲了的钢筋的平均应力—应变的曲线方程为[4]:

当εs≤εn时,σs=Esεs;

当εs>εn时,

其中,B为参数,ρ为配筋百分率;α2为外加主压应力与纵向钢筋间的夹角;ε为屈服起点处混凝土中软钢筋的平均应变,

2 计算结果的讨论

为了便于对比,本文将本构关系分为3组:第1组:忽略受拉混凝土的作用并且钢筋采用裸钢筋的本构关系,称之为简化的本构关系;第2组:仅考虑受拉混凝土的作用而钢筋仍采用裸钢筋的本构关系,称之为修正的本构关系;第3组:考虑受拉混凝土的作用且钢筋采用被混凝土加劲了的本构关系,称之为本文推荐的本构关系,现选取4根纯扭构件作为计算实例[5]。计算方法可参考文献[2]。最后的承载力和变形计算结果见表1。

从表1中可以看出:

1)忽略混凝土拉应力的影响是偏于保守的,将使承载力计算理论值小于试验值。但是最后计算构件破坏时的扭转角明显要大于试验值,因为忽略了混凝土的受拉作用,造成的偏差比较明显,试验值和理论值的比值为0.956,可见忽略混凝土的受拉作用,对构件的变形影响是比较大的。

2)钢筋的本构关系曲线由于采用了裸钢筋的理想弹塑性曲线,同样高估了钢筋的平均屈服强度,导致最后求得的极限扭矩要明显高于试验值,试验值和计算值比值为0.919,见表1。这种修正的本构关系方程,实质上是将钢筋在开裂处局部的应力—应变关系代替了钢筋的平均受拉应力—应变关系。高估了构件的极限扭矩,容易产生“混凝土强化”这一概念性的错误。

3)钢筋的本构关系曲线采用被混凝土加劲了的平均应力—应变曲线,同时考虑混凝土的“受拉刚化”,不仅能够正确估计受扭构件的扭转变形,而且又克服了修正的本构关系方程的高估钢筋屈服强度的缺点,最后求得极限扭矩和扭转角均和试验值较吻合。

3 结语

1)钢筋混凝土受扭构件计算中,开裂后受拉混凝土对构件的承载力影响很小,但是却在减小开裂后构件的变形上作用比较明显。如果忽略受拉混凝土的作用,将高估构件的变形。

2)构件开裂后,裂缝间的混凝土对钢筋有加劲作用,此时钢筋的力学性能和裸钢筋不同,如果采用裸钢筋的理想弹塑性本构关系,同样将高估构件的承载能力。

3)本文推荐采用的本构关系,较好的反映了构件的实际受力特点,计算结果与试验值吻合较好。

摘要：阐述了钢筋混凝土受扭构件开裂后受拉混凝土的作用,分析了其对受扭构件承载力和变形的影响,对计算模型中的受拉混凝土和钢筋的本构关系方程作了改进,并对受扭构件承载力和变形作了计算,得出理论结果和试验结果吻合较好的结论。

关键词：计算模型,应力—应变关系方程,极限承载力,变形

参考文献

[1]徐增全.钢筋混凝土薄膜元理论[J].建筑结构学报,1995(5):10-19.

[2]闫肖武.薄膜元理论在钢筋混凝土纯扭构件计算中的应用[J].淮海工学院学报,2003(4):63-66.

[3]刘继明.钢筋混凝土复合受力构件受扭行为和设计方法的研究[D].西安:西安建筑科技大学博士学位论文,2004.

[4]Pang,X.B.,Hsu,T.T.C..Behavior of Reinforced ConcreteMembrane Element in shear[J].ACI structural Journal,1995,92(6):665-679.

[5]丁金城,康谷贻,王士琴.轴力作用下钢筋混凝土构件扭转性能全过程分析[J].建筑结构学报,1987,8(1):1-10.

构件模型篇6

李亚平[1]在超声检测仪和动态测试分析仪的检测指标(混凝土声速、接收信号频率、接收信号首波振幅及接收信号波形完好程度)基础上,建立了基于这4个指标的混凝土缺陷评价的模糊综合评判模型。郑少瑛等[2]建立混凝土施工质量风险分析的17因素层次分析法模型。然而,混凝土质量不仅受到配合比,施工工艺,养护等因素的影响,还受到原材料质量、施工管理等因素的影响。鉴于此,本文将介绍另外一种评价方法,即模糊层次分析法(Fuzzy Analytical Hierarchy Process,简称F-AHP)[3][4]来建立影响钢筋混凝土构件质量的14因素评价模型,并将之用于对某工程钢筋混凝土梁质量的综合评价,取得了良好的效果。

1 模糊层次分析法模型

模糊层次分析法结合了专业知识与专家经验,利用模糊集理处理评定或决策中的不确定信息,这样能使评定结果更加定量化、直观化,比单一的层次分析法更能保证了评定结果的可靠性。本方法采用层次分析法(简称AHP)来计算各个指标的权重值,专家对各个因素单项评价,模糊计算来进行综合评价。

1.1 层次分析法的原理及基本步骤

1.1.1 评价指标及层次结构模型

影响钢筋混凝土构件质量主要有4个指标、14个因素[5][6][7][8][9],对各因素进行分析和分类,建立层次结构模型如图1所示。

1.1.2 构造判断矩阵及各指标权重计算[10]

根据AHP法,采用1~9标度进行各层相关指标和因素的两两比较,建立判断矩阵.其具体计算方法和步骤如下:

(1)将判断矩阵每一列如式(1)进行正规化

undefined

(2)将每一列经正规化后的判断矩阵按行相加

undefined

(3)对向量undefined正规化

undefined

所得到的w=[w1,w2,…,wn]T为所求特征向量,即相应因素的权重值

(4)矩阵最大特征根undefined; (4)

(5)一致性指标undefined(5)

(6)一致性比例undefined(6)

当时,则认为该判断矩阵具有满意的一致性,否则就需对该矩阵进行调整。其中为随机一致性指标,取值见表1。

1.2 模糊综合评判方法

如图1,将原材料质量、施工工艺、管理因素、环境因素这4个因素分别作为4个评价指标集,记作{U1,U2,U3,U4},并且,U1={D1,D2,…,D5};U2={D6,D7,…,D10} ;U3={D11,D12} ;U4={D13,D14} 。建立评语集V={V1,V2,V3,V4}={很好,较好,一般,差}。对U1,U2,U3,U4当中任意指标的评价为R=(r1i,r2i,r3ir4i),其中对U1 ;i=1,2,…,5;U2,i=1,2,…,5;U3,i=1,2;U4,i=1,2。式中:rij(J=1,2,3,4,5)为各指标在V集中各级评语的隶属度,评价模型为{U,V,R}。模糊评判矩阵R的建立很关键, 本方法采用专家对各个因素进行等级评价来建立模糊评判矩阵,具体的方法是:请相关领域的10名专家对各个因素进行等级评价,以评价等级的个数来建立评判矩阵R,然后根据AHP计算出的权重值和模糊判断矩阵进行模糊综合评价[3][4]。

2 实例计算

现以绵阳市仙海中心学校灾后重建工程小学教学楼钢筋混凝土框架梁设计为例,进行其质量的模糊层次综合评价。

2.1 各个因素权重计算

(1)各指标对于目标Z的权重计算及一致性检验见表2。

(2)因素D1,D2,D3,D4,D5对于U1的权重计算及一致性检验见表3。

(3)因素D6,D7,D8,D9,D10对于U2的权重计算及一致性检验见表4。

(4)因素D11,D12对于U3、U4的权重计算及一致性检验分别见表。

(5)因素D13,D14对于U3、U4的权重计算及一致性检验分别见表6。

2.2 建立模糊评判矩阵R

建立模糊评判矩阵R见表6。

2.3 模糊综合评价

(1)相对于各个指标的模糊评价