可扩展设计范文
可扩展设计范文（精选10篇）
可扩展设计 第1篇
关键词：数据库设计,可扩展,对象,关系数据库
0 引言
数据库设计是建立数据库及其应用系统的技术, 是信息系统开发和建设的核心。数据库设计是指对于给定的应用环境, 构造最优的数据库模式, 建立数据库及其应用系统, 使之能够有效地存储数据, 满足各种用户的应用要求 (信息要求和处理要求) 。
数据库设计的核心问题是建立模型。一般而言这个模型要满足两类准则:结构准则和性能准则。前者主要考虑如何保持数据的特性, 后者主要考虑资源的合理使用和数据库的存储效率。在所有数据库设计准则中最重要的原则是:最终产品必须满足用户的最终要求。但是, 首先需要存储的信息是动态的, 应用自身的发展也会产生新的和扩展的信息需求;其次, 信息化是分步进行的, 用户很难一次提出完整的需求;第三, 用户和设计人员之间存在理解上的差异。因此, 数据库应用系统在完成以后, 系统功能很可能不能完全满足用户需求, 而且随着时间的发展系统功能会逐渐偏离用户或企业的需求。所以, 数据库应用系统必须要不断地改进和扩展以适应环境的变化以及组织自身的发展需求。
目前数据库设计普遍采用“需求驱动”的数据库设计模式。但是, 如果在数据库设计阶段, 建立数据库模型时没有充分考虑到数据库应用系统以后可能的改变及扩展, 将使系统以后的维护工作变得极其困难, 甚至必须重新开发数据库应用系统。本文针对数据库应用系统开发过程中遇到的动态可扩展问题提出了一种数据库设计模型基于键值对的对象属性可扩展模型, 它区分了应用中的不同对象的类型, 通过设计属性分类提高了数据库应用系统中数据的可改变性和可扩展性。
1 信息系统中的传统数据库设计模型
通常, 在传统数据库设计模型中, 设计人员在设计阶段总是将数据信息表达的尽可能丰富, 使其不仅满足所有需求分析阶段得到的用户需求, 而且还要尽可能考虑到应用以后可能的改变以及扩展。采用这种方式设计的数据库应用不仅数据表过于“臃肿”, 而且对于未来的应用难于改变或者扩展。
例如, 在某校园建筑管理信息系统中, 系统成立初期, 只要求该系统能够展示建筑的基本信息, 如名称、简述等。设计人员有可能将数据表格设计成, 我们称之为方案1。包括编号、建筑名称、建筑描述是建筑的最基本属性, 此外设计人员也考虑到了系统将来的扩展, 加入了诸如建设日期, 高度, 等属性。由于设计人员不可能完全预见学校未来发展状况, 所以对于系统现阶段的需求来说, 尽管建筑信息表已经非常详尽了, 但是随着时间的推移系统仍有可能不适应实际需求。
随着需求的发展, 建筑的信息需求有可能发生变化。例如:①为了获取建筑质量, 有可能对该建筑的施工文件等信息保存;②随着校园信息系统的建立, 可能有更多的不同类型的建筑需要存入系统, 比如管道信息, 一些标志性雕塑, 或者植被信息;③随着系统的扩展, 原有数据表可能不能满足日益增多的该类建筑所有信息的存储, 所以需要建立新的数据表扩展其属性;④对于一些简单的建筑或者物体比如一棵树一个石凳, 存储的信息明显和一座教学楼不同, 需要按照类型的不同, 设计多个不同的数据表分别存储不同类型的物体信息。
2 数据库设计中的扩展性需求
在应用中, 类似这样的数据存储结构改变以及应用扩展的情况还有很多。如果用传统数据库设计模型, 那么在设计初始阶段就必须考虑到应用未来所有的改变及扩展, 尽可能使表格的信息详尽, 否则当应用发生改变或扩展时, 必须重新设计表结构, 并对应用程序中相关片段全部重写。如果同一变化出现在不同部位, 由于不同的原因, 出现在不同的阶段, 那么现有表结构不能满足要求;如果需要增加过多的对象属性信息, 那么表结构将必须修改。但是, 如果我们将数据对象化, 并采用定义其属性和值的设计模型, 上述问题将迎刃而解。
作为开发人员, 总会面对业务方提出的数据结构变化的需求, 字段的增加, 数据表的修改总是随时可能根据需求发生。因为业务在发展, 或者需求就有可能需要一个完全动态的可扩展的数据库设计方案, 但是以目前的关系数据库实现这种动态扩展的特性, 在系统一定规模之后所付出的代价是昂贵的, 也是不安全的。为了这种动态扩展性, 有这样三种常用的方法:
第一种方法:预留字段。既然很难加字段, 就预先留好一些备用, 但是这样没那么灵活, 有一定的实用性, 不过因为预先留的字段一般是没什么含义的, 需要有额外的信息来描述, 这种方法在扩展性要求不是太强的地方可以不影响性能的前提下提供一定的扩展性。
第二种方法:使用复杂字段。在某些特殊要求下还是很有用的, 比如, 某个业务实体 (某张表) , 有一些标记位, 都是true/false的标记, 可以理解为这个实体的一些属性, 经常需要添加, 这种情况, 在生产中我们使用过用一个数字, 按位来表示这些标记的, 比如第三位表示他是不是付费用户, 第四位表示他是合作方来的用户还是自己注册的, 等等。还有一种情况, 需要更复杂的属性列表, 属性个数经常变, 可以考虑使用一个文本字段, 保存结构化的数据, 然后在使用时需要动态解析该字段。使用复杂字段的好处就在于比较灵活, 同一类型的数据可以放在一起 (实际上相当于把应该是一个关联表的数据放一个字段里了) , 操作的性能也不错, 但是复杂字段里面的内容查询比较困难, 程序实现和修改起来也更复杂。
第三种方法:将数据的存储和索引 (需要查询的内容) 分开存放, 相当于主表就一个key-value, 把需要查询的字段放到其他单独的表里去, 这种方法对数据的实时查询的效率有一定的影响, 但是针对实时性的要求并不是所有系统都有要求的, 在有些地方是很好的解决方案。
3 基于键值对的对象属性可扩展模型
本文的基于键值对的对象属性可扩展模型就是结合上面提到的第三种方法, 使用数据表分别单独存储对象分类和分类的属性信息的定义, 并且实现了分类属性之间的树形的可扩展结构, 对象信息的存储用过一张表用来存储所有对象公有的可快速查询的数据信息, 另一张属性值表存储所有的对象的特有属性的key-value。通过这样的设计可以在不修改原数据表结构的前提下, 实现所有存储对象的动态可扩展, 如图1所示。
由图1所示, 表t_class保存对象的分类信息如建筑, 管道, 雕塑等;t_attibute_def保存的是每个分类所对应对象的属性信息如建筑的高度, 施工单位等;t_entity保存的是分类对象的公共信息, 是具体的物体如1号教学楼;t_entity_content保存每个具体的对象所有属性的信息值;t?倕_file表用来保存一些扩展的文件信息。通过这样一个模型我们可以在需要是动态定义一个大的分类并且可以动态的设置每个已有分类拥有哪些属性, 所有对象的的具体内容分别存储在对象公共信息表, 对象属性信息表和文件信息表中。
在实际应用中, 还涉及到属性冗余, 查询, 修改等方面的问题, 通过在校园管理系统中应用的结果来看, 这些都可以实现, 并能获得较好的效率。
4 结束语
综上所述, 传统的数据库设计适用于简单的、业务数据固定或变化极少的集中式数据库应用。在应用范围更广需要更灵活数据结构的系统中, 显然面向对象属性的扩展设计更加适宜。
随着网络环境的日益普及, 新的应用呈现出来的开放性与分布性特点, Web应用系统也由简单的数据库系统逐具有了更灵活多变应用环境, 在这种环境下, 能够满足扩展和动态改变的需求, 将有更广阔的应用前景。
参考文献
[1]萨师煊, 王珊.数据库系统概论 (第三版) [M].北京:高等教育出版社, 2000.
[2]刘洋, 高连生, 王斌.一种面向用户扩展的树状数据库设计模型[J].计算机工程与设计, 2006 (11) .
[3]陆登.基于对象数据库的扩展Java集合框架[J].计算机应用与软件, 2011 (12) .
可扩展设计 第2篇
根据人们对现代智能通信的需求，研究可扩展计算机网络软件系统的开发和设计，从而为计算机网络技术今后的发展提供建议。
1计算机网络设计软件的可扩展性
实现软件的可扩展性是所有软件开发人员的目的，其能够使软件的使用寿命有效延长，此种可扩展性不仅表现在软件规模方面，还表现在软件功能方面。基于可扩展性的计算机网络软件使用具有独特的功能，此种计算机网络技术的使用的扩展主要从三方面出发：
(1)软件功能。可视化软件功能的可扩展性主要表现为以下方面：通过网络技术功能的创新，在展现全新网络产品功能的基础上将软件网络化协议功能相互结合，实现网络技术发展的有效追踪。
(2)性能分析。在性能分析方面，以网络技术规模化的发展为基础，实现网络优化设计及使用。根据全新的性能模型，全面评价项目的设计质量。以软件使用能力的便捷化使用能够有效创建全新的性能模型结构。
(3)软件外部接口。在实现计算机软件外部接口的基础上，全面分析网络设计项目并且将其保存，重视网络设计管理的规范化，实现软件的优化设计，对软件外部接口进行全面优化，实现接口的可扩展性。
2系统的分析和实现
(1)系统的结构分析。以计算机网络设计的内容为基础，能够将软件分为四个基础功能：分别为系统调度模块，其主要目的就是实现系统功能的调度;网络拓扑设计模块，其主要目的就是设计可视化网络拓扑结构，并且划分子网、网络路由及网络设计参数;网络性能分析，其主要目的就是以软件系统的设计的性能需求为基础创建性能分析模型，全面分析网络的运行效果、安全性及开销;网络性能仿真，其主要目的就是实现网络的仿真运算。
为了有效实现系统软件外部功能的扩展，在设计过程中还要添加数据库接口模块，实现系统和数据库的接口连接，使用标准化数据库系统及软件系统完成接口设计，软件使用分层模型进行设置，将所有的功能模块相互结合，图1为系统的结构图。通过下图可以看出来，将软件分为两层结构，系统第一层主要包括调度模块，通过网络设计参数、对象实现和第二层接口实现此层的功能，并且将第二层和操作系统接口实现软件系统的调度功能。软件的第二层主要包括网路仿真模块、网络拓扑设计及性能分析，其主要目的就是實现软件的具体使用功能及软件的全新功能。根据基于数据库的多层软件体系结构，数据库结构的`主要目的及时连接数据库和其他软件系统，其虽然在软件系统中的，但是并没有被存放到分层结构中，其是一个独立的设备参数，将系统中的功能模块进行相互连接，其通过面向对象实现创建。软件其他部分的功能实现都是相互独立的，但是和网络设备参数和对象共享接口。在调用第二层功能的时候，软件第一层能够对数据访问接口进行更改。因为所有的数据都是根据共享数据进行，假如共享数据的结构不发生变化，网络功能扩展的主要目的就是创建完善的网络设备数据库。
(2)系统设计过程中的问题。在设计网络软件过程中，首先要进行网络拓扑图编辑及处理，在网络设计过程中，创建设备并且删除，从而实现划分设备，实现子网创建及管理。在网络配置过程中，根据网络的应用及配置优化进行项目化合理设计，并且进行数据库设计的优化及使用。在展示设备过程中，要实现设备工作的配置和仿真处理。
可扩展设计 第3篇
“向上扩展、向内扩展以及向外扩展是新版NetScaler最突出的特点之一。”思杰公司云网络集团副总裁兼总经理Klaus Oestermann表示。
Klaus对此进行了解释：“向上扩展”是指借助NetScaler的按需付费的模式，用户可以先按一个低配置的价格购买设备，在需要时可以付费升级，最多可以升级到原来的5倍速度；“向外扩展”是指借助TriScale技术的集群，可以即插即用的方式将设备无缝地添加到现有NetScaler设备组中，最多实现高达32倍的扩展能力；“向内扩展”是指其实现了与多功能NetScaler SDX平台的整合，以简化数据中心网络，最多可将多达40台独立管理的设备整合成为一个单一、易于管理的设备，运维管理大大简化。
据Klaus介绍，与云的连接也是NetScaler 10重点强化的能力。作为思杰云战略的重要组成部分，NetScaler 10内置了与Citrix CloudBridge的云连接能力，使用户可以更加轻松地将其企业数据中心扩展到外部基础设施。这一功能与Citrix收购Cloud.com公司后而鼎力支持的CloudStack配合，可以很好地支持企业负载在不同云之间的自由迁移。
值得一提的是，思杰的应用交付产品如今已经可以通过多种形式交付，可以是一个软硬件一体的产品（如NetScaler MPX），也可以是一个纯的软件产品（NetScaler VPX），部署到服务器上实现应用交付功能。NetScaler 10推出后，上述产品可以通过升级来享受到新版NetScaler的强大功能。
可扩展设计 第4篇
红外场景仿真在检验红外系统的图像处理与识别、目标识别算法方面具有极大的效益, 因此一直是研究热点。
国内的相关工作已进行很多, 有的研究者具体仿真了特定类型的目标的红外图像, 如南京理工大学的宣益民教授等人对卫星[1]、地面车辆[2]、海洋[3]等进行了深入分析与仿真。有的研究者运用特定算法仔细精确地计算了目标的红外辐射特性, 如哈尔滨工业大学的谈和平教授等人运用蒙特卡洛法详细求解了地面建筑物[4]的辐射换热与温度场分布情况。另外还有些研究者专门研究了目标和背景的合成办法, 比如浙江大学的王章野教授等人[5]提出了红外阴影的概念, 并尝试生成更具真实感的红外目标背景合成图。
但现有工作主要集中在特定场景、特定条件下的红外场景仿真, 系统化、集成化程度不高。同时, 如何合理设置软件结构与参数接口, 使得针对不同类型的目标、目标的不同模块均有专用算法合理处理, 也是一个亟待解决的问题。为此, 现描述了一个可扩展性良好、适应力强、仿真种类多样、移植性良好的红外仿真系统。红外仿真系统的核心在于红外辐射特性的建模与计算, 详细描述了对特定目标的建模求解过程。并给出了仿真结果。
1 红外仿真系统原理与组成
1.1 系统原理
红外场景仿真系统是指通过对目标、背景、大气环境、光学系统和探测器效应的分析、表征和重建, 生成各种条件下的高保真动态红外场景图像的系统。一般来说, 仿真过程为:首先收集信息, 建立目标的几何模型, 这一步通常可由3D MAX等建模工具实现。然后根据热辐射学理论, 建立目标的红外热辐射模型, 并迭代求出目标表面的温度场分布情况。然后由红外理论, 根据温度场及其它参数求出目标表面的辐射能量分布情况。并计算大气、光学系统、探测器对目标的辐射能量的衰减影响。最后利用三维渲染引擎将目标的几何信息与由辐射能量映射得到的灰度信息进行处理、光栅化, 生成一幅红外仿真图像。
1.2 系统难点
红外场景仿真系统最关键的工作在于目标温度场的求解。不同类型的目标, 其热辐射特性不同, 热物理属性不同, 并且运行的环境比如是高空还是陆地、是超声速运行还是低速行驶等也不同。这些都会对目标的温度场分布情况产生巨大的影响, 需要分别加以考虑。另外, 目标的不同部位, 也存在着不同的热辐射特性。以装甲车辆为例, 装甲车辆可被分为车身、炮塔、炮管、车轮、履带、发动机等不同功能模块。其中车身和炮管的形状不同, 一个接近长方体, 一个是圆柱体, 这使得其与空气的对流换热机理不同, 计算时应区别对待;并且车轮履带在运行过程中还会因摩擦产生热量, 使得温度高于车身装甲, 也应单独建模进行考虑。因此, 场景仿真系统如何快速有效地区别不同类型的目标与目标的不同功能模块, 是一个非常重要的问题。本文作者在研究中, 逐渐总结出一套有效的软件结构与接口, 并将在下文描述。
1.3 系统组成
红外场景仿真系统主要由如下模块组成:信息输入模块、坐标变换模块、红外热辐射建模模块、温度场迭代求解模块、灰度映射模块、投影与光栅化模块等组成。另外配合本系统的外围程序还有:目标的几何建模与转化软件、目标和相机的运动轨迹生成软件、仿真结果的回放软件等。
其中, 信息输入模块主要获取场景的目标与背景参数、目标的几何模型、目标和相机的运动轨迹、仿真场景的环境信息等。
坐标变换模块主要进行二项操作:首先根据目标运动轨迹信息将目标由模型空间变换到世界空间, 然后根据目标相机的相对位置与姿态信息将目标变换到相机空间, 也就是通常所说的观察空间。
红外热辐射建模模块和温度场迭代求解模块主要根据不同类型的目标, 以及目标的不同部位, 求出目标表面热辐射能量的分布情况, 找出合适的热物理参数如导热系数、对流换热系数等的计算方法, 分别建立各自的热平衡方程, 并将热平衡方程离散化, 采用合适的迭代算法迭代求解。
灰度映射模块则根据求得的温度场分布信息、探测器信息以及其它参数, 将温度信息转化为辐射能量信息, 并最终映射成灰度信息。
投影与光栅化模块则主要完成如下工作:将位于相机空间中的目标投影到相机平面也就是探测器焦平面上。并根据求得的灰度信息, 为探测器焦平面上的每个像素正确配色。最终生成一幅完整可靠的红外仿真图像。
1.4 软件接口与系统的可扩展性
一套设计合理又行之有效的软件接口对于红外场景仿真系统的可扩展性至关重要。由于系统需要仿真的目标种类繁多, 不同种类的目标的性质差异明显, 且目标各功能模块的红外辐射性质也各有不同, 因此, 在将目标输入到仿真系统中时, 应能提供诸如目标种类、目标各功能模块的详细参数信息, 帮助仿真系统正确区分不同的目标和不同的目标功能模块。
为此, 本系统进行了如下处理。
首先在利用3D MAX软件建模时, 按功能模块把目标分解成不同的对象, 并按照指定名称分别加以命名, 比如装甲车辆可被分解为cheshen, paota, paoguan, lǜdai, chelun, engine等对象。然后将目标模型导出为ASE文件。并根据需要将ASE模型文件转化为仿真系统自定义的FTG格式。
FTG文件在文件头中先存放了模型总体信息结构体, 内含本目标的目标类型、对象总数、顶点总数、面元总数、材质总数等信息;然后依次为每个对象存放一个对象信息结构体, 内含对象类型、对象的顶点索引起始值与顶点数、面元索引起始值与面元数、材质索引起始值与材质数等信息;然后才是目标模型的核心数据:依次存放目标模型的顶点 (含顶点位置及顶点法线) 、面元 (含面元的三个顶点的索引以及材质索引) 、材质 (含发射率、透过率吸收率等) 等数据。若是空中目标, 则模型还要包括尾焰的数量与位置大小等信息。这里目标类型对象类型都是预先设置好的整形数值, 每一个值对应不同的含义, 如表1和表2所示。在进行红外辐射建模计算时, 只需根据这里的头文件信息, 就可以确定每个顶点及面元所属的模块, 为其正确选择合适的红外热辐射模型, 从而获得合理的结果。
如果需要对系统仿真的目标类型进行扩展, 或是对目标特定的功能模块进一步细化, 不必改动原有代码, 只需要新增目标类型和对象类型的定义以及处理函数, 并在3D MAX中对对象进行进一步的划分即可。这种处理方法, 解决了以往仿真系统只能仿真单一目标, 并且无法区分目标的不同模块, 只能用单一模型统一简化处理的不足, 提高了系统的适应性与可扩展性。
2 红外辐射建模与求解
2.1 热平衡方程
红外目标一直不断以辐射、对流和传导方式与外界环境发生热交换。地面目标如装甲车辆等受内热源、太阳辐射、天空及地面背景辐射、周围大气的对流换热、车轮履带之间的摩擦生热的影响。下面以装甲车辆为例, 建立热平衡方程。
按功能划分, 装甲车辆可被分解为车身、炮塔、炮管、车轮、履带、发动机等等部分。车身、车轮履带、发动机的热平衡方程分别如方程式 (1) ～式 (3) 所示。
其中Ecd, i是第i个单元与相邻单元的导热能量, Esun, i、Eenv, i分别是太阳、天地背景对第i个单元的辐照能量, Erad, i是单元自身的红外辐射能量, Ecv是单元与大气的对流换热能量, Efric是摩擦产生的能量, Eeng是内热源发动机产生的能量。
运用蒙特卡洛法[4]求解上述方程的主要计算公式如下
公式 (5) 右边第一项代表了太阳一次辐照 (直射和散射) 到单元i的能量, 右边第二项代表了太阳辐照 (直射和散射) 经一次或多次反射后到达单元i的能量。
公式中:ki代表单元i的导热系数, Si是其面积, dij是二个单元的有效热传导距离, Hsun是太阳的辐照度, S′p, i是在单元在垂直于太阳入射方向上的投影面积 (考虑了其它单元的遮挡之后) , αi是单元对太阳辐射的吸收率, P1和P2分别是太阳入射能量中直射和散射的份额, Rsunj, i是太阳照射到单元j的辐射能量经过一次或多次反射后到达单元i的份额, σ是斯蒂芬-波耳兹曼常数, εi是单元的发射率, Ri, j是单元i辐射的能量直接到达或经过若干次反射后到达单元j的份额, hi是对流换热系数。
2.2 方程迭代求解
热平衡方程的未知元多, 未知项次数高, 求解计算量很大。为了简化计算, 本文采用了源项线性化法, 如方程 (8) 所示, 将方程的未知项从四次降为一次, 然后采用高斯-塞德尔迭代算法进行线性方程组的迭代求解。
方程 (8) 中带*号的表示是上一次迭代的已知结果, 不带*号的是这一次待求的未知量。利用方程 (8) 对方程 (6) 进行化简 (未知量为Ti) , 可得:
经过源项线性化后, 未知项Ti由四次项化简为一次项, 从而使方程组可用线性方程组处理办法迭代求解。
3 仿真结果与展望
利用本仿真平台生成的部分仿真结果如图1图3所示。在实际应用中, 本仿真系统显示了包容性强、可扩展性良好的处理能力。另外, 由于未采用DirectX等商用引擎而是采用标准C语言专门编写, 使得本仿真系统不受限于特定平台, 可以在将来根据实际需要移植到不同的操作平台中, 进一步扩大应用范围。
摘要：红外场景仿真对于科研现代化具有重要意义。一个良好的红外场景仿真系统应该扩展性好, 支持多种目标平台如飞行目标、地面目标、海面目标等;同时仿真模式多样, 支持温度场在线、离线计算, 支持各种参数的输入;而且应能够方便地移植到多种操作平台如PC机或专用硬件板卡上。以上三点对国内现有研究提出了更高的要求。本文描述了一种可扩展、多模式、平台独立的红外场景仿真系统。该系统合理设计了参数接口, 使得各种类型的目标以及目标的不同模块均能得到合适的处理;支持温度场在线迭代计算, 以及离线预计算;同时采用标准C语言独立编写了三维渲染引擎, 而不是借助于DirectX, OpenGL等商用引擎, 使得系统本身可方便移植到各类平台如DSP板上;并给出了该系统的部分仿真结果。
关键词：红外场景仿真系统,可扩展,平台独立,装甲车辆,辐射建模
参考文献
[1]韩玉阁宣益民.卫星的红外辐射特征研究.红外与激光工程, 2005;34 (1) :34—37
[2]韩玉阁, 宣益民, 吴轩.装甲车辆红外热像模拟及数据前后处理技术.南京理工大学学报, 1997;21 (4) :313—316
[3]张伟清, 宣益民, 韩玉阁.全球海洋表面红外图像的计算机模拟.红外技术, 2006;28 (3) :170—173
[4]谢鸣, 李玉秀, 徐辉, 等.建筑物温度场理论建模研究及逐时计算.工程热物理学报, 2004;25 (6) :1013—1015
可扩展设计 第5篇
不废话 —— 集成 Google 、 baidu 、 zoomeye 、 bing 搜索引擎，特定 URL网站搜集、特定 cms 网站搜集、 C 段、旁站、二级域名查询一条龙服务。
4.2 cms 识别
1 、构造特定 url ，判断 http 响应
首先我们收集了各种 cms 和框架的特征目录，当需要对一个网站进行指纹识别时，我们将作为参数的 URL 处理成根目录 URL 的形式，之后把处理后的 URL 与特征目录拼接起来，之后连接，得到 HTTP 响应代码，如果为 200 或者 403 则一般可以判断该目录是存在的，则存在该特征目录的可以确定采用了哪种 cms 。
2 、爬行页面链接，匹配特征 URL
第一种识别方式一个缺点是文件的上级目录不可确定，也就是说，如果我们把特征文件放到了一个自己命名的目录下，第一种识别方式是不能识别的。那么我们就使用一个 spider 来爬行网站上的链接，比如 a 标签下的 href 属性， src 属性，link 标签下的 href 属性，爬行到这些标签之后与特征目录进行匹配，判断是否包含特征目录，这样就可以确定为何种 cms 。
3 、 web 指纹识别插件
4.3 漏洞扫描
内置基于 get 请求的反射型 XSS 和 GET 型 sql 注入模块，不做详细说明。
提供了漏洞扫描插件编写接口。
4.4 漏洞利用1. 低配置漏洞利用
我们搜集了一些使用 url 触发的 cms 漏洞，低配置漏洞利用会连接指定网站的漏洞触发 url ，如果存在会返回结果。当然，低配置漏洞利用是极不精确的，所以，我们编写了高配置漏洞利用模块。
2 、高配置漏洞利用
可扩展设计 第6篇
近年来, 随着国内外学者的大量研究, 一些感性工学应用系统已初见成效[2,3]。这些系统应用于具体产品的设计与客户化配置等方面, 并且它们的一个共同特点就是将单一具体的感性数据分析算法集成在系统中, 然而感性工学的应用是一个复杂且可变通性高的过程, 对于不同的产品需要选择适合产品特点的感性数据分析方法才能保证真实的掌握消费者对于产品的感性观点[4], 同时由于当前感性工学的研究尚不深入, 没有一个标准而有效的分析方法, 随着感性工学的不断研究发展, 感性数据分析方法的发展变化与更新是必然的。因而在设计感性工学系统时对分析方法建立一种可扩展的机制是非常重要的。本文正是在这一种现状下建立了一个可扩展分析方法的感性工学应用系统, 并且提出了一种扩展分析方法的策略, 通过该策略可以方便地将新研究出的分析方法扩展到感性工学辅助设计系统中, 从而使辅助设计系统逐步完善。
1 系统简介
感性工学辅助设计系统主要完成将消费者所抱有的意向转变成物理特性的产品设计要素。该系统按感性工学实施流程经由收集产品样本、感性意象语意资料, 并结合产品的基本设计元素进行多次用户调研, 通过集群分析、因子分析、回归分析等分析方法建立感性意向与产品造型的量化关系, 以辅助设计师设计出符合用户心理的产品设计方案。根据感性工学的研究理论和应用模型, 该系统采用C/B/S结构, 如图1。划分为4个模块, 由图2所示, 分别为: (1) 生成代表性样本模块该模块主要在对产品样本调研基础上, 采用多元尺度法、集群分析法对原始样本进行分群操作, 并生成每一群的代表性的样本。 (2) 生成代表性的意象语意模块该模块主要是在生成的代表性样本的基础上, 进行意象语意调研, 通过因子分析法[5], 得到符合样本意象的代表性的意象语意。 (3) 感性意向与造型元素关系量化模块该模块主要是在设计师输入构造的样本的基本造型元素, 进行再次调研, 通过诸如回归分析等方法, 构造意象语意与造型映射量化关系法则, 用于求解符合消费者心理感受的造型参数。 (4) 验证分析结果可信度模块该模块是为了进一步验证系统分析生成的设计元素是否与消费者的心理感受相符, 采用T校验的方法验证分析结果的可信度。
2 可扩展分析方法的实现
从上面系统介绍可知, 系统模块的核心是各模块对应的感性数据分析方法。引言中论述了感性数据分析方法扩展性的必要性。本文正是在此基础上提出了一个可扩展数据分析的方法, 当研究出新的分析方法之后, 通过该扩展方法便可以很方便地配置更新到上面的系统中, 提高系统的可信度。
2.1 实现框架
根据系统的模块划分, 可扩展分析方法的实现框架如图3。主要有三部分组成, 一是S语言解释器引擎, 它完成执行从xml算法配置文件中获得的相应分析算法, 将数据反馈回各个模块;二是虚线框内的算法解析与执行模块, 数据分析的主要工作都在这部分完成, 从数据库获取数据组织成输入矩阵, 通过解析算法配置文件config.xml取得相应算法, 将S解释器引擎执行算法后返回的数据更新到数据库;三是xml算法配置部分, 分析算法的扩展功能主要在该部分实现。
2.2 详细设计
2.2.1 S语言执行引擎实现
S语言是AT&T推出的统计学编程语言, 主要应用于统计学领域的研究与程序开发。目前几个支持编程的主流统计学软件SAS、SPLUS、R等都实现了对S语言应用。本系统通过抽象出S语言的执行器类实现算法的执行与配置分离, 从而达到扩展的目的。用面向对象的方法封装一个S语言执行引擎类CSengine, 提供成员操作符<<与>>的重载, 前者向执行器中输入S语言程序源码执行, 后者将执行结果取出。每个分析算法通过xml配置文件解析到系统中, 然后由CSengine完成执行, 如图3中虚箭头所示。根据不同的统计学软件提供的S语言API可以使CSengine有多种实现, 这也方便S语言执行引擎类将来具体实现的改变, 在本系统中采用SPLUS的API。
2.2.2 分析模块与分析算法间的接口
每一个分析模块都有一个分析算法与之相对应。以集群分析为例, 集群分析模块由泛型类CCulter Analysis实现, 其内部有一个泛化的函数对象, 即与之对应的分析方法, 当采用Pam分群算法时, 通过实例化一个CCulter Analysis
2.2.3 分析算法的选择
分析模块具体选择采用什么样的分析算法, 这部分的功能在一系列的XML文件中配置完成。XML文件分为两类, 其中一类是算法配置文件config.xml, 另一类是具体算法实现文件, 下面对这两类进行具体说明。
配置选用算法通过单个文件config.xml实现, 下面是一个XML配置文件:
log-level用于日志级别的配置, 与log-level在同一节点层次的有三个算法节点culter-algorithm、factoralgorithm、map-algorithm, 分别用于配置集群分析、因子分析以及语意与造型元素映射分析的算法选择, 每个算法配置节点下面的模式是一样的。以集群分析为例, 该节点下面有两类子节点, product与parameter。因为针对不同的产品可能要采用不同的分析算法, product节点正是用于特殊产品算法的配置, 通过后面的name以及type属性可以知道该节点是针对bottle产品的算法, 对应算法是下层子节点parameter中name为b-kmeans的算法, 具体算法在path所指路径的xml文件中。
具体的算法实现由一组XML文件配置, 一个算法对应一个文件, 下面是一个kmean算法实现配置文件:
根节点是算法的入口函数, 这里是kmean函数, 具体的定义在下面name为kmean的function子节点中, 具体实现即的中间部分, 用S语言编写, 可以调用系统中的S函数, 也可以在主函数上方按函数定义配置方式增加自定义函数, 如上面用于求样本间距离的distance函数。
分析算法模块首选查找算法选择配置文件config.xml中相应的算法节点, 如集群分析或因子分析等, 然后在该节点下面查找是否有对应产品的算法并根据product节点type属性中的算法名字找相应算法实现文件的路径, 进而将算法取进S解释器引擎用于数据分析;如果在算法节点下没有找到相应产品的节点, 则采用算法配置节点type属性中的默认算法, 同样去查找实现的文件。在找到具体算法实现的XML文件后, 按顺序将各个自定义S语言函数读入S引擎, 然后调用入口函数进行数据分析。
3 实例
按照上面的实现方法可以方便地更改需要使用的方法, 如需要在集群分析中使用默认的kmean算法, 则只需要在外部XML文件中改变节点
3.1 算法设计以及算法实现的配置
在研究出专门使用于bottle集群分析的pam算法之后, 为了将该算法扩展进本系统, 需要先配置算法的实现文件, 对其命名为b-pam.xml, 该算法只有一个自定义函数, 具体配置如下:
3.2 将新算法配置到系统
当完成新算法的实现配置之后, 需要将该算法应用到系统中, 这时主要通过修改算法选择配置文件config xml完成。在集群算法节点
这样算法分析模块在查找算法时便能针对bottle产品使用新增加的b-pam算法, 从而方便地实现算法的扩展。
4 结语
现今国内外学者研究出的感性工学应用系统将具体的分析算法固定在系统中, 因而很难扩展, 然而感性工学的研究尚在初级阶段, 并没有一个统一标准的算法, 同时针对不同的产品可能采用的分析方法也有所不同, 随着今后感性工学研究的不断深入, 对系统实现算法的扩展既重要也很必要。本文在这样一种研究现状的基础上, 实现了一个集成的感性工学辅助系统, 并具体阐述了分析算法扩展的实现机制。通过修改或增加相应的XML配置文件方便地完成新算法的增加和变更, 使系统不断完善可靠。本系统的算法扩展机制为感性工学应用系统的建立提出了一个新的思路。
摘要：当前感性工学研究中对不同产品数据的分析方法多种多样, 没有一个标准, 随着研究的深入, 对感性工学辅助设计系统分析算法的灵活扩展完善是非常必要的。然而现今的系统将一种分析方法固定于其中, 很难做到对不同产品扩展和灵活的分析算法策略。文章结合这种系统的特点, 提出了一种可扩展数据分析方法的机制。该方法通过XML文件实现算法配置和扩展, 方便地将新研究出的分析方法扩展到系统中, 从而使辅助设计系统逐步完善。
关键词：感性工学,可扩展,辅助设计,S语言,XML
参考文献
[1]Nagamachi M.1997Kansei Engineering and Comfort[J].International Journal of Industrial Ergonomics, 1997, 19:79-80.
[2]黄琦, 孙守迁.基于意象认知模型的骑车草图设计技术研究[J].浙江大学学报 (工学版) , 2006, 40 (4) :553-559.
[3]邝俊生, 江平宇.基于感性工学的产品客户化配置设计[J].计算机辅助设计与图形学学报, 2007, 19 (2) :178-183.
可扩展设计 第7篇
利用组件技术的语言无关性质，我们可以设计出可扩展的程序模块，可使应用程序得到最大程度上的复用，这样有效缩短了软件开发的周期，降低了开发的成本。本论文将要介绍到的可扩展数据库环境配置组件就是基于组件思想设计的，它是一个Windows应用程序，在VB6环境下开发。底层实现采用到Geostar4提供的GeoDatabaseBuilder组件、GeoEvents组件以及ConnectProperties组件，用来实现数据库元数据表的创建并且提供创建过程中产生的信息。
1 组件对象模型（COM)
在COM之下，软件组件通过一个或多个COM对象来实现其服务功能。但是对象不是组件之间的直接联系，组件通过对象支持的接口来使用对象的功能，通常一个COM对象支持一个或多个接口，而每个接口又支持或实现若干个方法，一个方法是完成某个特定任务的函数或过程，COM对象之间的接触都必须通过接口来进行，一个接口之下的方法通常都是相互关联的。
COM是基于面向对象的模型，在一定程度上，它与面向对象编程(如C++)有相似之处，同时也有很大的差别，每个COM对象是一个类的实例。COM对象支持面向对象三大特性：抽象、多态和继承。
COM对象和接口由图1所示方式来表示的。接口是一个小圈圈加一短线与对象相连，图中向上的接口是一个十分特别的接口，称为IUnknown，是每个对象和接口都必须支持的最基本的接口。
每个接口都有两个“名字”。一个是供人用的，一个是供软件用的。供人用的名称是一串字符，必须保证在一个程序内唯一，而供软件用的名字是一个相当大的整数，它必须保证全球的唯一性，也就是说，在任何情况下，两个不同的接口有不同的标识码，称之为全球唯一标识码(Global Unique Identifier，简称为GUID)。按照惯例，供人用的名称总是以I开头如IUnknown, ISomeInterface。接口可以用不同的方式定义，一般是用接口描述语言(IDL)去描述。
2 组件结构
可扩展数据库环境配置组件由3个部分构成：GeoWizardFactory、GeoWizardSheet、GeoWizardPage。另外还包括两个基本模块：GeoWizardDBClass以及PublicModule。
(1) GeoWizardFactory类：暴露给用户，供用户使用的组件接口，包括SetWizardMode以及DoModal两个方法。如图2所示。
(2) GeoWizardSheet类：该类对应程序中WizardSheet页面，用以承载GeoWizardPage，负责页面的初始化，加载，切换，并载切换时执行当前页面对应的功能。如图3所示。
(3) GeoWizardPage类：该类对应这程序中OracleDbPage、SqlServerDbPage以及AccessDbPage等页面，用以接受输入参数，以便为执行相应功能做准备。如图4所示。
(4) GeoWizardDBClass类：该类提供不同数据库服务器的对应数据库服务功能接口的实现，提供了所有的操作数据库的功能接口，并且包括了配置功能接口。目前已经实现了OracleDBClass、SqlServerDBClass以及AccessDBClass。如图5所示。
(5) PublicModule公共模块，为其他类公用，提供了API函数声明，主要数据结构的定义，以及错误处理函数，日志处理函数等功能接口。
3 组件框图
图6为组件的设计框图，包含关系表明了组件之间的调用和被调用关系。
4 组件扩展方案
4.1 扩展方案概述
目前该数据库配置组件只支持Oracle, SqlServer, Access 3种类型的数据库，随着GeoStar版本的不断升级，在不久的将来，可能会支持更多类型的商用数据库，例如DB2, SDE, IN-FOMIX等等。为此我们的组件提供了可扩展的特性，以方便其与GeoStar版本的升级同步。
4.2 扩展步骤
[Step0]在geoDataSource中增加扩展数据库的类型字符串以及相应ID值。
[Step1]构造扩展数据库的WizardPage页，使之继承自GeoWizardPage类，并实现GeoWizardPage的接口函数。
[Step2]编写功能类，提供数据库操作接口，例如ConnectToDB, CreateDB等等，以及配置操作接口，例如InitDbEnv, UpgradeDbEnv, ClearDbEnv等等。
[Step3]在GeoWizardSheet中定义页面对象。
[Step4]修改资源文件，完成版本切换所必须步骤，详细操作步骤请参考版本解决方案章节。
[Step5]扩展完成。
5 结束语
可扩展数据库配置组件是为GeoStar定制的一款数据库配置工具，它运用了在软件设计中广泛使用的COM技术，使得该工具具备极好的扩展性，在GeoStar的频繁升级中，避免了数据库配置模块重写，提高了开发效率，节约了开发成本。
参考文献
[1]GeoStar4.0二次开发手册[G].武汉武大吉奥技术有限公司, 2005 (6) .
[2][美]DALE ROGERSON.COM技术内幕[M].杨秀章, 译.北京:清华大学出版社, 1999.
[3]CORRY, MAYFIELD, CADMAN.COM/DCOM编程指南[M].刘云, 孔雷, 译.北京:清华大学出版社, 2000.
[4]潘爱民.COM原理与应用[M].北京:清华大学出版社, 1999.
可扩展设计 第8篇
1 XML及Web Service技术介绍
可扩展标记语言 (XML) 可以用来标记数据、定义数据类型, 是一种允许用户对自己的标记语言进行定义的源语言。其非常适合万维网传输, 提供统一的方法来描述和交换独立于应用程序或供应商的结构化数据。目前, XML已经成为Web上使用的一种通用数据格式。由于其具有开放性和结构化的特点, 使之能够在用户和程序之间任意交换数据, 而不受平台限制。XML文档格式的管理信息可以很容易地通过超文本传输协议 (HTTP) 传输, 由于HTTP是建立在TCP之上的, 故管理数据能够可靠传输。
Web Service是一个平台独立的、低耦合的、自包含的、基于可编程的Web的应用程序, 可使用开放的XML (标准通用标记语言下的一个子集) 标准来描述、发布、发现、协调和配置这些应用程序, 用于开发分布式的互操作的应用程序。Web Service, 可使用开放的XML标准来描述、协调和配置这些应用程序, 用于开发分布式的互操作的应用程序。它不依赖于任何第三方的软件和硬件。Web service体系结构 (如图1) 包括了服务注册中心、服务提供者、服务请求者3 种实体以及发现、发布、绑定3 种操作。
2 平台体系结构及说明
采用微软.Net Web Service技术实现平台功能, 对外提供统一的Web Service接口调用方式:public string Interface Method (string in_xml) , 所有的数据交互均通过该方法作为统一入口, 减少其他系统调用的复杂性。
数据库中建立相应表结构用于配置接口的类型, 以及不同接口类型所对应的接口实现类名称。
采用动态反射技术调用不同的系统接口, 减少接口之间的耦合。采用可视化界面对接口管理平台中的接口进行统一管理。
当业务系统向平台发送请求调用数据时, 接口管理系统根据请求数据中的请求类型从数据库中查询相应接口实现类, 通过反射进行实例化, 获取相应数据传送给调用的业务系统。
2.1 接口平台功能设计与实现
接口是各系统间对接的门户, 在设计时至少要遵循四个原则:简单原则:首先接口方法的命名要规范, 每个对外提供的方法都应有意义, 让用户通过名称猜测到方法的主要用途;其次要求接口中的相关参数数据类型要尽可能简单, 尽量少用嵌套层次多的数据结构:第三方法要尽可能单一。封闭原则:模块功能的实现细节要完全对外封闭, 且在对模块内部的处理逻辑进行修改时, 不会影响模块使用者的调用。完整性原则:接口中模块功能是一个全面的整体, 提高代码复用率。可置换原则。为接口提供标准的接口规范, 这样将来可以轻松的用遵循接口规范的新模块置换原有模块, 而不会影响其它相关模块的调用方式。
2.2 定义服务接口
接口地址定义:http://XXXXXX:20049/RYEService.asmx
接口方法为:public string Interface Method (string in_xml)
输入参数为:In_xml, 其中In_xml需要遵循如下既定格式:
<?xml version="1.0"encoding="utf-8"?>
<Interface Info Equip Type ID="JYSQD">
<In Data>
<![CDATA[各业务系统交互数据]]>
</In Data>
</Interface Info>
Interface Info为根节点, Equip Type ID属性为接口的类型, 判断调用程序调用哪一个数据处理解析程序。
In Data节点中的数据为业务系统所要求的数据采用CDATA节点进行数据输入, 确保可以解析各种格式数据。此处数据根据业务系统的不同需求进行数据传输。
输出参数为:Out_xml, 其中Out_xml格式需要遵循如下既定格式:
<?xml version="1.0"encoding="utf-8"?>
<Return Info Flag="1"Error Info="">
</Return Info>
Return Info为根节点, 其中节点属性Flag为1 时表示调用成功, 为0 时表示调用失败。属性Error Info中数据为调用失败时返回的错误信息。Return Info中的值为实际的返回数据, 根据调用的接口不同, 内容将不同。
3 结语
基于Web Service和XML技术的可扩展接口管理平台, 平台本身脱离了业务数据, 而且各个业务功能之间实现完全没有耦合, 减少业务变动而造成原有功能的异常。有如下几点优点:第一, 通用性强, 本管理平台采用了通用的Web Service和XML技术, 目前主流的编程语言均对其有着较好的支持, 各类系统均能进行对接, 扩展性强, 采用采用工厂模式进行设计, 扩展性强, 对于以后新增接口的加入, 仅需要实现相应的方法类, 并引入到工厂中进行, 无需变动原有程序实现方法, 不影响原有业务。第二, 业务和平台分离, 平台本身不参与业务数据流, 仅对数据的流向进行控制, 并管理接口调用, 其业务本身的数据使用, 在各自的类和方法中实现, 从而实现了接口业务和接口管理平台的分离。第三, 实现和建设成本低, 目前行业中也存在功能强大的, 业务实现全面的ESB企业服务总线, 但价格昂贵, 动辄数百万。本接口管理平台, 采用微软的.NET技术, 实现相对简单, 逻辑也相对简单, 同时能满足医院各类信息系统直接的调用管理。
医院信息化建设是现在数字医院建设的重要组成部分, 通过基于Web Service和XML技术实现通用的接口管理平台, 极大的降低了接口间的复杂关系, 能够满足医院各系统间的相互调用要求, 从而提高医院管理工作的效率, 提高医疗服务质量。
参考文献
[1]陈蓓, 李志.一种基于Web service技术的医院数据整合方法[J].中国卫生信息管理杂志, 2009, 6 (4) :59-62.
可扩展设计 第9篇
随着信息技术的发展,战场信息的探测和收集手段越来越多,这对信息的处理与展现提出了很大的挑战。人对信息最直观的认识来源于视觉和听觉。而对于战场综合情报而言,最直观的表现方式是图形。由于战场态势复杂多变,需要各专业人员进行分析与处理。处理完后,如何以一种统一的方式展现在很大程度上决定了情报的效用。因此,构建一个可扩展的开放式图形展现框架是指挥信息系统的必然需要。
同时,从软件的角度来看,可扩展性作为软件的非功能性属性意义重大,它在一定程度上决定了软件的生命力。可扩展性好的软件能够适应各种变化,能够很快的响应用户的需求。因此,软件开发者总是力求提高软件的可扩展性。良好的设计是可扩展性的保障,插件式开发作为一种良好的设计得到了广泛的应用。Eclipse就是插件式开发的典型案例。Eclipse基于OSGi(Open Services Gateway Initiative,OSGi,开放服务网关协议),开发者按照其规范开发的插件能够无缝集成到Eclipse软件中。
1 战场态势展现要素分析
战场态势总体分为两大类:动态目标情报和静态部署情报。其中动态目标情报包括:雷达情报、技侦情报、电抗情报等,静态部署情报包括:机场、港口、兵力部署等军事部署信息。此外,在综合态势之上还可根据实时态势叠加作战计划等信息,进行作战推演评估,拟制修改作战计划。如图1所示为战场态势综合集成展现示意图。
图1中,“原始态势数据”来源有:雷达站、观通站探测的实时目标数据,作战标准数据库的静态部署数据、作战计划数据和评估模型数据等。这些数据都会通过“统一信息传递平台”发送给综合态势展现终端,综合态势展现终端通过各处理模块对这些数据进行预处理,并通过统一图形绘制命令进行图形绘制,将数据图形化显示。此外,综合态势展现终端具有与展现数据的干预交互能力,能够在态势图上拟制修改作战计划。
如何对各处理模块进行有效的管理(加载、调用等)决定了综合态势展现终端的可扩展性和实用性。好的模块管理方法能够按需集成多个数据处理模块,又不增加软件的复杂度,能够提高软件的稳定性和展现的效果。
2 可扩展开放图形框架XOGF
针对战场综合态势展现的要求,本文提出了一种可扩展开放图形框架XOGF(e Xtend Open Graphic Frame),用于有效管理和集成基于态势图的业务处理模块。本节将对XOGF的主体思想和工作原理进行介绍。
2.1 系统组成
可扩展开放图形框架(以下简称图形框架)是一个提供图形插件式开发的基础平台,由一个核心部件和一系列管理部件组成,其体系结构如图2所示。
从图2可以看出,基于图形框架的应用软件有三个组成部分:
(1)核心部件
图形框架核心部件的作用是:加载插件,调用插件的标准化响应函数,负责插件间信息交互。
(2)管理部件
图形框架管理部件的作用是管理插件(增加、删除、更改优先级),分配命令码和干预命令,管理操作对象。管理部件具有六个子部件:插件管理器、命令码分配器、干预命令分配器、操作对象管理器、插件生成器和日志分析器。
(3)插件
插件是依据一定准则开发的能够应用于图形框架软件以达到扩充其能力的动态库。这些准则由核心部分制定。
2.2 工作原理
如图3所示为图形框架组件关系图。主程序通过插件表来加载插件,插件管理自己的菜单和工具栏。当主程序触发事件后,核心部件将其分发给各插件,各插件决定是否要响应这一事件。然而,不同的事件会产生不同的状态,而不同的状态会决定下一事件应该由哪个插件响应。由于各插件之间是自治的和自完备的,如何保证某一插件响应事件后系统状态的变化能够被其他插件感知而又不破坏插件的自治性和完备性是图形框架设计的重点和难点。我们将这一问题分解为三个核心问题:(1)插件间如何通信;(2)如何确定系统的唯一状态;(3)右键菜单如何组合。下面将分别讨论这三个问题。
2.2.1 插件间通信
XOGF有两类插件通信问题:(1)核心部件与插件间的通信问题;(2)插件之间的通信问题。
对于问题(1),框架核心部件向插件传输信息的问题已解决,如图4所示,通过调用插件的标准导出函数来实现;而插件向框架核心部件的信息传输可通过向主程序发送消息,再由主程序转发给框架核心部件。
对于问题(2),插件通过核心部件中转信息。插件间通信的方式有两种:主动获取与被动接收。无论是哪种模式,都需要一块内存区域来存储通信的“信息”。图5示意了插件如何主动获取与被动接收信息。
插件间的通信主要应用于两种场景:(1)某一插件状态发生改变通知其他插件;(2)某插件选中了其导出对象,要将导出对象的信息传给依赖于他的插件,这种情况主要应用于右键菜单的合并。
2.2.2 确定系统的唯一状态
图形操作交互式事件有三类:按钮事件(菜单和工具栏产生的事件)、鼠标事件和键盘事件。在程序中,一个动作有可能由单个事件直接完成,也可能由事件引起,由随后产生的若干个事件完成。对于由单个事件直接完成的动作不会引起状态的变化。由若干个事件完成的动作在动作发生时其它插件处于休眠状态。为了更好地说明事件、动作与状态变化的关系,下面对相关术语进行定义:
(1)动作
动作指一个操作单元,如在要图标绘时绘制平行四边形、折线,放大/缩小地图,求地图两点距离,等等。动作可以由“动作事件”完成,也可以由“动作触发事件”引起,进一步由鼠标事件、键盘事件完成。
(2)状态
我们将“动作”视为“状态”,状态的变迁由按钮事件(指动作触发事件)引起,但按钮事件(指动作事件)并不一定会引起状态的变迁。我们用两个元素来唯一确定一个状态:插件的激活状态和插件内部状态。插件的激活状态由图形框架核心部件统一管理,而插件内部状态由插件自身进行管理。插件的激活状态通过为插件增加一个变量进行标识。我们认为通常插件之间是互斥的,即当一个插件被动作触发事件激活时,其它插件应被通知休眠。插件向核心部件通告其状态,核心部件据此决定其它插件的状态。核心部件的处理流程如图6所示。
只有在“动作触发事件”发生时才需要确定插件的唯一状态,动作触发事件的事件争用问题可通过插件的状态机制来解决。动作触发事件引起的动作由若干鼠标事件和键盘事件完成。在动作发生时,只有响应了动作触发事件的插件处于激活状态,其它的插件处于休眠状态。因此,插件中的鼠标事件和键盘事件需要根据是否处于激活状态来触发。
2.2.3 右键菜单组合
在图形界面上操作时,有时会需要弹出右键菜单。右键菜单可能只来自于某个插件,也可能同时来自于某几个插件,后者涉及到右键菜单组合的问题。此问题解决方法为:右键菜单的弹出需要指出“操作对象”,没有操作对象就没有右键菜单,对插件导出的右键菜单进行组合。解决右键菜单组合问题应以“操作对象”(简称“对象”)为中心,遵循三个原则:1)每个插件导出操作对象;2)每个插件给出要操作(依赖)的操作对象;3)对具有相同操作对象的插件定义其优先级。此优先级用于右键菜单组合时的前后顺序。默认的优先级为插件加载的顺序(越先加载优先级越高)。插件的加载顺序取决于插件的依赖关系,而插件的依赖关系则取决于对象的依赖关系。“操作对象”是关系依赖的最小粒度。在插件描述文件中,给出了各插件的导出对象和导入(依赖)对象。在软件形成前,先要根据导出对象和导入对象计算出插件的依赖关系,形成插件的优先级,并将优先级写到插件描述文件中。
右键菜单只有在多个插件要操作同一个对象时才要组合。因此,当导出对象的插件要弹出与导出对象相关的菜单时,该插件需要向其他依赖他的插件发送对象的相关消息。为每个对象开辟一个存储空间,用于存储对象的信息。插件根据对象的信息决定是否要创建并返回右键菜单,框架核心部件将多个右键菜单拼接起来。
如图7所示,为两个插件右键菜单组合流程的示意图。当主程序调用核心部件加载右键菜单时,核心部件依据插件加载的顺序获得插件的右键菜单进行组合。当同一个对象有多个插件要对其进行操作时(即多个插件要返回右键菜单),操作对象所在的插件将操作对象的数据写到共享数据区中。依赖此对象的插件将根据共享区中的内容决定创建何种右键菜单。
3 XOGF的实现及应用
目前,已经基于VC6.0和VS2008实现了XOGF,并已应用到某一体化指挥平台和某联合情报处理系统中,两个系统均已实装,担负部队日常值班任务。本节将对XOGF实现的关键思路进行描述。
3.1 核心部件
XOGF核心部件的作用是:加载插件,调用插件的标准化响应函数,负责插件间信息交互。核心部件由插件表、插件标准函数抽象类和相关配置文件组成。
3.1.1 插件标准函数抽象类
核心部件需要定义插件标准函数抽象类作为插件的实现准则和规范。类中的标准函数都是图形操作常用函数,并提供了扩展能力的函数。这些函数接口包括:初始化插件、创建系统工具栏、创建系统菜单、执行命令码、更新菜单状态、执行干预命令、绘制图形、弹出上下文菜单、定时器响应、鼠标按键、鼠标移动、键盘按键、处理报文、获取插件信息、释放插件。
插件标准函数抽象类还描述了插件信息,包括:插件名称、动态库名称、插件命令码处理范围、插件版本和开发者信息。
3.1.2 插件表
核心部件通过插件表来加载并调用插件的功能。插件表中每个插件元素包含的信息为:插件调入优先级、插件信息表、插件句柄、插件接口指针等。
3.1.3 核心配置文件格式设计
核心部件依赖一系列的配置文件进行工作,这些配置文件包括:1)插件描述文件;2)插件框架命令码范围定义文件。
插件描述文件描述了插件的信息,由插件生成器生成,由插件管理器进行管理,程序员在开发插件前必须先获得此文件。插件描述文件应该包括以下信息:插件名称、插件动态库名称、优先级、版本号、开发者信息、命令码处理范围、插件导入对象和插件导出对象。插件描述文件使用XML格式。
插件核心部件将会根据导出和依赖的对象决定插件的优先级(第一级优先级),然后根据配置文件中的“优先级”决定第二级优先级。由于同一插件导出和依赖的对象有多个,因此由导出和依赖的对象计算出的插件优先级有可能发生冲突。这种冲突在设计插件时是要避免的。在操作对象管理器中,将通过对象依赖图的形式来查找这种冲突。
插件框架命令码范围定义文件使用XML格式,描述了插件框架中插件可分配使用的命令码范围,由命令码分配器负责管理。
3.2 管理部件
图形框架管理部件的作用是管理插件(增加、删除、更改优先级),分配命令码和干预命令,管理操作对象。管理部件的六个子部件为插件的生成和开发提供便利,其功能描述如下:
1)插件管理器
插件管理器是一个应用程序,用于为一个应用载入、删除插件,调整插件的优先级。插件管理器在应用运行前工作,应用运行时插件管理器产生的更改只有在应用下次运行时才生效。
2)命令码分配器
因为每个插件可处理的命令码不能重叠,因此需要统一分配各插件可使用的命令码范围。这项工作可由命令码分配器来完成。
3)干预命令分配器
用于分配干预命令由哪个插件响应。
(4)操作对象管理器
用于指定插件的导出对象、依赖对象,对象的优先级。
(5)插件生成器
插件生成器是一个应用程序,应用于插件开发阶段,用于生成插件原始必要代码和插件描述文件。程序员要开发新插件时必须由插件生成器生成插件原始必要代码和插件描述文件,并在此基础上进行二次开发。
插件生成器还依赖于命令码分配器和操作对象管理器。
(6)日志分析器
日志分析器是一个独立的应用程序,用于控制日志打印,以便于软件集成联试。日志分析器支持文件打印和窗口打印,支持日志分类打印和单步打印。日志的单步打印指日志分析器收到日志消息后,将日志分析器程序挂起,直到某个事件触发日志分析器,日志分析器继续执行。
4 总结
XOGF解决了指挥信息系统中如何组合展现复杂战场态势的难题,提出了一种基于插件的模块组装机制,实现插件的即插即用,能够综合显示多专业战场态势。但是,XOGF并没有考虑如何有效组合软件主菜单和工具栏,也没有考虑如何将状态栏的空间分配给各插件。在后续工作中,将对这两个问题进行重点研究,设计一套规则和工具,用于编排主菜单、工具栏和状态栏的内容。
摘要：战场态势是作战决策的依据,是交战双方指挥员关注的焦点。针对多源态势可视化显示的实际需求,本文提出了一种可扩展开放图形框架XOGF(eXtend Open Graphic Frame),用于有效管理和集成基于态势图的业务处理模块,实现基于同一幅态势图的战场态势可视化显示。通过实际应用表明,XOGF能够有效解决多源战场态势的组合显示问题。
关键词：战场态势,可扩展,插件
参考文献
[1]邓亚明,杨邦荣.基于ECLIPSE图形插件开发的研究[J].电脑开发与应用,2009.第22卷第2期
[2]刘亚滨,杨红.精通Eclipse[M].北京:电子工业出版社,2004
[3]刘俊平,邹江南,贺玉寅.美军战场态势感知能力分析[J].国防信息化,2007.第6期
[4]李苏军,吴玲达,胡世才,宁汉辰.数字化海战场态势表现系统研究[M].系统仿真学报,2009.第21卷第19期
[5]蔡志浩,彭晓源.基于地理信息系统的虚拟战场态势显示[J].系统仿真学报,2003.第15卷第7期
[6]杨沁梅,孙晓鸣.基于插件集成技术的通用陆战场态势图,2012.第10期
可扩展设计 第10篇
本文是对AVCON IP视频监控在普通电信网络基础上,研究并实现先进的视频监控与多媒体数据交互功能的应用。根据市场需求,通过本系统,可建立基于软件模式可即时扩展的IP网络数字视频监控网并可实现多点实时远程视频监控。
1 传统视频监控的主要问题
基于监控室的传统视频监控解决方案中包含硬件视频监控和软件视频监控两大解决方案。硬件解决方案中最大的缺憾是需要固定的线路和固定的监控地点,并且依赖于昂贵的硬件投资。因此对于大范围视频监控,无论是基础建设还是监控点扩充都存在很大的局限性,并且缺乏管理的灵活性。在一些软件解决方案中多点控制单元(MCU)多采用软件方式设计,用以实现多点信息交换的功能,而对于MCU中多点媒体控制(MC)和多点媒体处理(MP)而言,带宽和服务器系统的限制是所有软件解决方案中难以克服的瓶颈,直接影响服务系统的稳定、视频图像的质量以及监控点的容量。
视频监控整体结构的合理性也影响着视频监控的效果,对于大多数视频监控中的数据交换瓶颈往往是由于实际与会者的分布状况造成的,而单纯从带宽瓶颈上着手解决的方案不会获得太大的效果。另外,为保护用户在以往硬件设备中的投资,或者为今后的系统扩展,视频监控的兼容性也显得尤其重要。如果不具备标准协议支持,一些视频监控就不能很好的和硬件兼容,和其它视频监控系统兼容。
2 AVCON视频监控的关键技术
AVCON网络视频监控系统是基于Internet、支持实时流式传输、播放和交互的流媒体应用系统。
2.1 分布式多级智能中转技术
路由式软MCU解决多路音视频的分发控制,MCU可以分布在不同域,支持多级级联,功能上将上行和下行媒体服务器分开,可以并存同一服务器,也可以是不同服务器,这样使得系统具有很好的延展性。根据路由算法自动选择最优路径中转媒体流。MCU支持系统容错,当MCU发生故障或媒体流使用超过限制,系统可以将MCU媒体流自动转发到其他可用MCU。
2.2 扩展模块控制协议
控制协议保证数据在传输过程中的安全、快速、有序和高可靠性。该协议以网络传输控制协议和数据包控制协议为基础,定义了应用层会话初始协议。扩展模块控制协议专门为网络视频监控的数据交互而设计,通过数据传输可靠性验证UDP协议保证数据的稳定和高速传输。在今后的数据传输方案中,将采用下行组播、上行单播的方式,进一步增强系统容量。
2.3 音视频编码、传输技术
系统利用MPEG-4的优势,从MPEG-4数据编解码和数据包的组包传输等方面进一步优化处理。提供高达1920*1024的超高分辨率(四路合并),色彩深度达到32bit,对传输速率要求较低,图像压缩传输码流带宽可在20K-6M选择。网络视频窗口的帧率能到30帧每秒,MPEG-4利用很窄的带宽,通过帧重建技术、数据压缩,以求用最少的数据获得最佳的图像质量。音频支持GSM6.10音频标准和其他通用音频标准,支持多路混音技术,确保实现视音频同步,容易辨识不同发言对象的声音特征,真正达到了逼真效果。另外,通过对音频流的智能修包纠错,使得连续3个数据包都可在300ms内得以修复(音频延时<=300ms),保证声音连续、不破碎。系统采用MMX优化指令对H.263视频解码进行后置处理,提高视频图像的输出品质。支持MS DirectX 8.1网络视频采集技术,实现了极高效率网络视频活动网络视频的捕捉和采集,使该系统拥有较低的开销并可提供更高的服务效率。同时支持UDP和TCP两种传输模式。
2.4 自适应速率调整策略
用软件算法预测出下一时刻的有效带宽后,采用自适应速率调整机制,根据目标传输速率调整视频比特流的实际输出速率,使之与带宽相匹配。使用的控制策略为:在用户可用带宽比较低的情况下,只发送MPEG4视频流的I帧,这样可以尽量减少网络拥塞的发生,同时使用户得到可以接受的图像质量。当可用带宽有所增加时,逐渐增加发送P帧的个数,这样可以充分使用网络带宽,并提高视频质量。对于B帧则不进行发送。发送过程中的速率控制流程如图一所示,以当前发送帧速率为基础,在每个I帧后多发送一个P帧(直到发送完全部视频帧为止);当带宽减小时,在每个I帧后少发送一个P帧(直到只发送I帧为止)。在实际的控制转发速率过程中,可以根据当的网络状况先计算得到一个合适的初始发送帧数,然后按照图一所示来完成发送帧速率控制。如图1。
3 系统组成与实施方案
3.1 系统组成
如图2所示,AVCON视频监控系统由三部分组成:
控制中心:完成组织监控通道及通道控制功能;完成网站服务更新、系统维护、权限设置功能等。
多点音视频分发控制单元(MCU):完成多路音视频的分发控制,支持多个级联。
信号采集端:采集视频信号,通过四路采集卡或8路采集卡可以接多路视频信号。
客户端:同时可收看多路视频信号。
3.2 实施方案
AVCON网络视频监控系统的实施方案主要包含四个方面的内容:硬件设备配置、系统软件平台、应用软件部署、网络带宽资源需求。
3.2.1 应用软件系统
AVCON网络视频监控系统示,包含管理中心(用户部门管理、权限及资源分配、会议控制)、转播代理服务(MCU)、认证服务以及数据库系统。转播代理服务模块可以分布在许多网络节点上,相互进行实时视、音频和数据流的交换、转播。其智能流技术保证使网络上的流数量和带宽降到最低。
3.2.2 系统软件平台
根据应用软件的部署模式,中心服务器细分为中心管理服务器、数据库服务器。管理服务器提供视频监控中心控制服务和Web服务;为分担中心管理服务器的负载,数据库服务器可采用独立服务器提供数据服务,也为今后数据的扩展(分布式存储、并行服务、双机备份与容错等)提供条件。认证服务器单独部署有利于减轻中心认证的负载,而且可以将认证服务布置在任何分中心或主节点。甚至可和MCU服务器并行,如表1。
3.2.3 硬件设备配置
硬件设备的数量要求需要根据系统的应用环境确定,如果不计算分节点(多机构)的情况,采用简单多用户并发计算如表2。
3.2.4 网络带宽资源
网络带宽资源需要根据具体网络结构计算,表3只是网络资源的基本要求。
4 结束语
利用本监控产品对远端现场的图像声音及其它数据实时监控,具体方式:把前端采集的视/音频信号编码成MPEG-4格式,通过互联网或内联网,传输到监控中心,在中心对数据进行适当处理,使得到授权的用户可以通过网络查看监控对象。因为某些情况需要24小时监控,对设备稳定性要求较高,应选择较稳定的前端采集卡。
参考文献
[1]Zhang Q,Zhu W,Zhang Y.Network2adaptive Rate Control with TCP2Friendly Protocol for Multiple Video Objects[C].IEEE International Conference on Multi2media and Expo(ICME),New York,2000.
[2]Yee J R,Weldon E J.Evaluation of the performance of error correcting codes on a Gilbert channel[J].IEEE Trans.Comm,1995,43(8):231622323.
[3]王海波,李宾,李晓飞.嵌入式MPEG-2远程网络视频监控系统的实现[J].电子工程师,2003(3):31-34.
可扩展设计范文
声明：除非特别标注，否则均为本站原创文章，转载时请以链接形式注明文章出处。如若本站内容侵犯了原著者的合法权益，可联系本站删除。
