基于模型软件开发

基于模型软件开发（精选12篇）

基于模型软件开发 第1篇

1 理论概述

1.1 计算机支持的协同工作

“计算机支持的协同工作”定义为[2]:地域分散的一个群体借助计算机及其网络技术,共同协调与协作来完成一项任务。它包括协同工作系统的建设、群体工作方式研究和支持群体工作的相关技术研究、应用系统的开发等部分。目前CSCW的研究集中在协同设计、访问控制、协同机制等方面。

1.2 协作模型

协作模型是CSCW系统的核心和基础,其目的是描述群体协作的方式、机制、管理、协调以及对协作过程的控制等[3]。

在不同应用背景下的CSCW协同工作模型会有很大差异,从CSCW出现到发展至今产生了许多协作模型,如会话模型、会议模型、过程模型、活动模型以及层次抽象模型等,从各个不同的方面对群体协作加以抽象。会话模型定义了两人之间的交互协作关系;会议模型描述了多人之间进行交互协作的方式;过程模型和活动模型则是刻画了共同完成任务的协作各方的分工和协作过程。但现实世界中往往需要不同层次和不同方式的协作才能完成一项任务,单一的协作模型也就不足以能满足对协同任务的协作方式和过程的描述。因此,对于一些具体的任务往往要采用多种模型混合,按不同层次加以描述。

Flavio提出了以通信、会话和会议相结合的三层协作模型[4]来描述一个会议系统的协调控制的结构。而Vin H.M等人用会议、活动、合作三个层次来抽象群体协同动作[5]。清华大学在并行工程的基础上提出了面向对象多层次协同模型[2]。罗杰文等人把表示与推理应用到主体的具体设计中,提出基于动态描述逻辑的多主体协作模型[6]。

2 软件开发协作模型

在CSCW定义的基础上,软件协同开发可定义为:软件组织利用计算机网络、多媒体以及人机接口技术,将时间上分离、空间上分布、工作上相互依赖的多个协作成员及其活动有机地组织起来,共同完成某项软件开发任务的分布式协同工作过程。软件开发过程由一系列任务组成,任务往往由称为活动的子任务组成,而活动又可分解为更具体的操作,正是这种协同工作的层次结构决定了软件开发的协作模型是一种层次结构。

根据软件开发工作的层次特点,本文在清华大学的面向对象多层次协同模型的基础上提出任务、活动和操作三层结构的软件开发协作模型,将软件开发中的协同工作划分为任务模型层、活动模型层和操作模型层,分别采用下文介绍的过程模型、活动模型和会议、会话模型进行描述,如图1所示。

2.1 任务模型层

软件开发是一个复合过程,可以分解为一系列相互关联而又相对独立的串行或并行的任务或子任务,整个任务的集合构成了软件过程。对于不同的软件过程,任务划分的方式可能不同,如RUP就将软件过程划分为九个工作流,每个工作流可以看作一个粗粒度的任务。任务模型层具体使用“过程模型”来描述,使用项目管理技术或工作流技术来实现。任务模型层可以看作对软件过程的宏观分解,分解得到的结果是一个粗粒度的工作流。任务分解结构(Work Breakdown Structure,WBS)是项目任务分解的常用方法。

2.2 活动模型层

每项具体的任务可以分解为一系列相互关联而又相对独立的串行或并行的活动,形成一个工作流,涉及到具体的角色和资源。活动模型层具体使用“活动模型”来描述,使用活动理论或工作流技术来实现。活动模型层可以看作对软件过程的微观分解,分解得到的结果是一个细粒度的工作流。

2.3 操作模型层

每项活动由具体操作序列构成,操作可以看成特定时刻拥有特定权限的角色使用特定工具对工件的改变。操作之间的关系可以是串行或并行。操作可以分为独占操作、并发操作和协同操作,其中并发操作和协同操作是这一层主要解决的问题。操作模型层根据不同的协作情况使用“会话模型”、“会议模型”等来描述,使用具体的协作支持工具来实现。

3 软件开发协作模型的形式化定义

定义1基本元素集合E={ROL,RTF,TOL,GOL,USR},即角色集ROL,工件集RTF,工具集TOL,目标集GOL,成员集USR。

定义2操作OPR={ROL,RTF,TOL,fOPR},fOPR:RTF2TOL是一个映射,描述工具和工件之间的对应关系。特定角色的操作为OPR rol={rol,RTF,TOL,fOPR},rol∈ROL,OPR rol∈OPR。描述特定角色使用特定工具在工件上的操作。

定义3活动ACT={ROL,OPR,f ACT},f ACT:ACT2OPR是一个映射,描述活动和操作之间的映射关系。特定角色的活动为ACT rol={rol,OPR,f ACT},rol∈ROL,ACT rol∈ACT。活动由特定角色承担,由一组操作构成,活动和操作之间具有映射关系。

定义4活动结构关系ASR={ACT,f ASR},f ASR:ACTACT{True,False}是一个映射,活动结构关系描述了一项任务中各个不同活动之间的亲子关系,如果两个活动之间存在着直接父子关系,则?ASR为True,否则?ASR为False。

定义5任务TSK={ROL,ACT,f TSK},f TSK:TSK2ACT是一个映射,描述任务和活动之间的映射关系。特定角色的任务为TSK rol={rol,ACT,f TSK},rol∈ROL,TSK rol∈TSK。任务由特定角色承担,可以根据任务和活动之间的映射关系分解成若干相互协同的活动。

定义6任务结构关系TSR={TSK,f TSR},f TSR:TSKTSK{True,False}是一个映射,任务结构关系描述了不同任务之间的亲子关系,如果两个任务之间存在着直接父子关系,则f TSR为True,否则f TSR为False。

定义7访问控制关系ACC={ROL,OPR,RTF,fACC},f ACC:ROLT2OPR是一个映射,访问控制关系描述特定角色在特定时间T对工件所能进行的操作。

定义8角色扮演关系RAR={USR,ROL,fRAR},f RAR:USRT2ROL是一个映射,角色扮演关系描述群体活动中的成员在特定时间T承担的角色。特定用户的角色扮演关系为RARusr={usr,ROL,fRAR},usr∈USR,RARusr∈RAR。

定义9群体GRP={USR,f GGR},fGGR:G2USR是一个映射,描述群体的结构关系。

定义10软件过程PRC={GRP,GOL,TSK,f PRC},f PRC:GOL2TSK是一个映射,描述目标到任务的映射关系。协作开发过程定义为群体为共同目标所执行的一组任务。

定义11关系集合R={fOPR,f ACT,f ASR,f TSK,f TSR,fACC,f RAR,fGGR,f PRC},即操作关系fOPR,活动-操作映射关系,活动结构关系f ASR,任务-活动映射关系f TSK,任务结构关系f TSR,访问控制关系fACC,角色扮演关系fRAR,群体结构关系fGGR,目标-任务映射关系f PRC。

定义12软件开发协作模型SDCM可以描述为三元组。表示软件开发协作模型由基本元素E构成,执行任务TSK、活动ACT、操作OPR三层构成的软件过程PRC,并遵循R所确定的关系。

4 应用实例

软件开发协作模型适用于建立任何软件过程的协作模型。Rational统一过程(Rational Unified Process,RUP)是基于UML和构件式架构的迭代增量型开发过程,包括6个核心工作流:业务建模、需求分析、系统分析与设计、实现、测试和部署,3个支持工作流:配置与变更管理、项目管理和环境[7,8]。

RUP协作模型定义为:

PRC={Rational统一过程}

TSK={业务建模,需求,分析和设计,实现,测试,部署,配置和变更管理,项目管理,环境}

以下仅以“业务建模”为例展开,其他子过程的细化限于篇幅不再细述。

ACT业务建模={评估业务状态,描述当前业务,定义业务过程,精化业务过程定义,设计业务过程实现,精化角色和职责,探索过程自动化,开发领域模型}

OPR业务建模={ROL业务建模,RTF业务建模,TOL业务建模}

ROL业务建模={业务过程分析人员,业务设计人员,项目相关人员,业务评审员}

RTF业务建模={业务构想文档,业务用例模型,业务分析模型,目标组织评估,业务规则,补充业务规格说明,业务术语表,业务架构文档}

TOL业务建模={可视化业务建模,模型生成和维护}

5 结论

现有CSCW的理论与技术不完全适用于软件开发领域下的协同工作,有必要研究软件开发语境下的协作模型。针对软件协同开发的特点,本文在分析和利用现有协作模型的基础上,建立了任务、活动和操作三层结构的软件开发协作模型,对模型及其基本元素给出形式化定义,并应用于建立RUP协作模型。模型的应用实例证明该软件开发协作模型能够较好地描述软件开发过程的协作模式。

摘要：协作模型是CSCW系统的核心和基础,其目的是描述群体协作的方式、机制、管理、协调以及对协作过程的控制等。该文从软件协同开发的特点出发,在分析和利用现有协作模型的基础上,建立了任务、活动和操作三层结构的软件开发协作模型,给出模型及其基本元素的形式化定义,并将其应用于建立RUP协作模型。

关键词：计算机支持的协同工作,协作模型,软件开发,过程建模,统一软件过程

参考文献

[1]Bandinelli S,Di Nitto E,Fuggetta A.Supporting cooperation in the SPADE-1environment[J].IEEE Transactions on Software Engineering,1996,22(12):841-865.

[2]史美林,向勇,杨光信.计算机支持的协同工作理论与应用[M].北京:电子工业出版社,2000.

[3]郑庆华,李人厚.CSCW的一种建模与实现方法[J].计算机学报,1998(21):270-276.

[4]Depaoli F,Tisato F.A Model for Real Time Cooperation[R].Proc.of CSCW'91,1991.

[5]Robinson J A.Communications services architecture for CSCW[J].Computer Communications,1994,17(5).

[6]罗杰文,史忠植,王茂光,等.基于动态描述逻辑的多主体协作模型[J].计算机研究与发展,2006,43(8):1317-1322.

[7]Kruchten P.The Rational Unified Process an Introduction[M].Boston:Addison Wesley,2000.

基于模型的软件测试技术探析论文 第2篇

基于模型的`软件测试技术根据被测试应用程序的分析设计模型，自动生成测试模型、产生测试用例和进行测试结果评价。

2.2 软件测试自动化水平及测试效率高

基于模型的软件测试在测试过程中，首先提高了软件测试效率，减少了测试人员的工作量；其次在软件成本降低的同时，软件产品质量提高了；最后，可以随时生成各种统计数据，提高高层监控整个软件测试过程的能力。

2.3 有效解决了测试失效辨识问题

基于模型的软件测试技术是对其他软件测试技术的有效补充，往往能发现其他测试技术难以发现的故障，尤其是对逻辑复杂故障测试效果好，保障了软件质量。

3 模型的软件测试存在的主要问题

模型的软件测试工作是一项具体且全面的工作过程。首先，工作人员方面，不仅需要测试人员具备一定的理论基础，还要掌握相关工具使用方法。其次，在实际应用过程中，我们发现基于模型的软件测试技术存在不少软件质量问题，尚不能取代已有的其他测试技术，还需从事此行业的工作人员进一步研究和实践，更好的补充其他测试技术不足之处。以下简述了存在的几个主要问题并进行了简要分析。

3.1 误报问题

误报问题是系统没有发生故障而报警，误报信息是模型的软件测试技术普遍存在的问题。这是由于一些故障的发生和确定是在动态的信息执行中形成的，而基于模型的软件测试技术大多是静态分析技术，误报问题在静态分析的测试工具工作中是不可避免的。以下以OCL在建模的进程调度系统中的静态模型为例，见图1。 图1 静态模型 上图是对系统的静态描述，虽然可以形成所需模型，但是显然对该系统的描述还是不精确的。我们知道，处在就绪状态的进程和等待进入就绪状态的进程集合之间是不相交的，而系统中始终只能有一个处于活动状态的进程，活动进程与前两个进程也不会发生集合。这样，静态图的生成并不是准确的，误报问题由此产生。现在不少高校和研究所将动态测试与静态测试进行互配测试，以期解决测试中的误报问题。

3.2 漏报问题

基于模型软件开发 第3篇

摘 要：目前，各种各样的学习平台和学习终端层出不穷。因此，面对多样化的终端设备，我们在开发应用程序时考虑如何实现在不同设备的无差异化移植显得越来越重要。如何运用相关技术保证跨终端、跨平台的统一用户体验，这是值得探索的问题。针对一般的三维物理模型存在跨平台问题，文章通过研究WebGL技术在构建三维物理模型中的应用，提出了利用浏览器对WebGL的支持来解决跨平台问题的方法。该方法通过HTML5中Canvas画布获得三维绘制场景，在该场景中利用WebGL第三方库（three.js）构建三维物理模型，然后由浏览器对模型进行渲染，从而解决跨平台问题。研究结果表明，WebGL技术的应用为三维物理模型的构建提供了新的思路，克服了跨平台问题，极大地支持泛在学习，适应教育新常态——创客教育。

关键词：三维模型；WebGL；跨平台；设计与开发；

中图分类号：G434 文献标志码：A 文章编号：1673-8454（2016）06-0075-05

一、引言

随着计算机技术和网络技术的快速发展，虚拟现实和三维可视化技术已成为时下Web技术的焦点。近年来3D技术因其开发和设计上的突出优势而被广泛应用在软件行业、3D硬件行业、数字娱乐行业、制造业、建筑业、虚拟现实、地理信息GIS以及3D互联网等行业[1]。然而当互联网时代的热潮还未褪去时，移动互联网时代已悄然来临。随着手机、Pad等移动设备的普及，越来越多的学校逐步开始尝试开放移动终端进入课堂，更进一步将移动设备引入教与学的过程。为更好地实现信息化创新教学，实现教师教学方式的改变与学生学习方式的转变，促进学生的知识建构，实现泛在学习、无缝学习，实现创客教育。那么如何使教学资源体现出交互性、移动性、智能化，以更好地适应课堂教学方式的变革？这对我们开发相关应用程序和教学资源提出了更大挑战：如何运用相关技术保证跨终端、跨平台的统一用户体验？

在过去，Web3D技术主要依赖不同的插件，为了展示3D效果，用户不得不安装各种插件，跨平台性较差。随着HTML5技术近年来的迅猛发展[2]，这种状况得到了极大改善。特别是随着HTML5标准的进一步规范和完善，其提供的新特性和新标签能更好地适应现今多终端访问需求。目前，更多的主流浏览器如Chrome、Firefox、Safari、Opera以及IE11等对HTML5和WebGL提供了较好的支持。因此，我们可以在浏览器内部实现3D图形的硬件加速，创建3D游戏或其他高级的3D图形应用程序，从而使其在不同终端运行成为可能。

在此背景下，本文针对一般三维物理模型存在开发复杂、硬件要求高以及移植不便等问题，研究了WebGL技术在构建三维物理模型中的应用，提出了利用浏览器对WebGL的支持来解决跨平台问题的方法。该方法利用图形硬件加速图形绘制，有着较快的调用速度，通过HTML5中Canvas画布获得三维绘制场景，在该场景中利用WebGL第三方库（three.js）构建三维物理模型，然后由浏览器对模型进行渲染和运行。该技术使用方便，不需要任何插件，增加了复用性和灵活性，且更容易得到跨平台的支持，如Windows、Mac OS、Linux、Android和iOS等操作系统的支持。WebGL技术的应用不仅可以克服跨平台问题，为无缝学习提供很好的支持，而且为构建三维物理模型做出了有益的探索和尝试。

二、无缝学习与创客教育

1.学习新常态——无缝学习

无缝学习是以社会学习、情景学习、知识建构为理论基础，在移动设备下进行的一对一数字化学习[3]。

移动终端设备的普及，人们对教与学资源的碎片化、可视化需求，在WebGL技术下能很好地实现三维物理模型的可视化，使学生能更好地理解，符合学生的认知。基于WebGL技术的三维物理模型能适合于各种系统软件和移动设备，在互联网+时代，能更好地适应学生利用碎片化时间进行无缝学习，促进学生学习方式的转变，也能很好地适应翻转课堂教学。

2.教育新常态——创客教育

创客教育是一种融合信息技术、秉承“开放创新、探究体验”教育理念，以“创造中学”为主要学习方式和以培养各类创新人才为目的的新型教育模式[4]。在创客教育中，教师角色的转变，从关注知识技能教学，转向培养学生终身发展能力和思维的教学，学生角色的转变，从知识的灌输到知识建构，在做中学，促进学生知识建构和创造性思维培养。基于WebGL技术开发的三维物理模型能促进学生的知识建构，培养学生高级思维技能，引领学生高级思维的发展，能引导教师从浅层学习走向深层学习的教学策略，有利于学生创造性思维的培养。

随着信息技术的发展、智能手机的普及，面对信息技术与教育教学深度融合的今天，人们对移动学习资源建设越来越重视，能更好地促进学生的无缝学习，在互联网时代，学生对碎片化思维与碎片化知识的需求，有利于学生学习方式的转变。基于WebGL技术开发的三维物理模型在物理课堂中的应用将是信息化教学创新必不可少的，三维物理模型的可视化与交互性能更好地促进学生的知识建构，有利于培养学生的创造性思维，为实现智慧教育提供可能。

三、WebGL技术简介

1.WebGL技术

WebGL是一个用来在Web上生成三维图形效果的应用编程接口，也是一种3D绘图标准，这种绘图技术标准允许把JavaScript和OpenGL ES 2.0结合在一起，通过增加OpenGL ES 2.0的一个JavaScript绑定[5]，WebGL可以为HTML5 Canvas提供硬件3D加速渲染，这样Web开发人员就可以借助系统显卡在浏览器里更流畅地展示3D场景和模型，还能创建更为复杂的导航和数据视觉化。WebGL技术直接利用JavaScript编程创建3D场景和动画，非常复杂且容易出错。框架的应用极大地简化了开发步骤，提高了开发效率，且更易维护和更新。目前已有大量基于WebGL技术的JavaScript库正在开发以加快创建3D图形的速度，如GLGE、SceneJS、Three.js等。本文主要采用Three.js开发框架来实现三维物理模型的开发。Three.js是一个很出色的开发框架，该框架以简单、直观的方式封装了WebGL底层的图形接口，从而降低了WebGL的使用难度，并且完全开源[6]。它提供了一个JavaScript应用程序接口，允许在浏览器端未安装任何插件的情况下进行2D/3D硬件加速渲染。

2.三维场景Web显示设计

在三维场景绘制之前，首先需要获取HTML5的canvas元素，然后通过该元素获得WebGL的绘制环境。在该上下文环境中，由Three.js通过以下6个基本步骤创建三维模型：

（1）设置场景：场景变量是一个三维空间，相当于一个大容器，用于存储和跟踪我们要渲染的所有物体的轨迹。场景设置没有很复杂的操作，只需要进行实例化，然后再依次将相机、灯光、模型等加入场景即可。

（2）设置相机：要渲染一个场景，我们需要一个相机来决定我们在渲染场景时能看到什么。在 Three.js 中能够指定透视投影和正投影两种方式的相机。

（3）设置光源：在一个场景中可以设置多个光源。Three.js中可以设置点光源、聚光灯、平行光源和环境光等。可根据具体场景模型和需求，添加适合的一种光源或几种光源的组合。

（4）设置模型：场景可以添加需要渲染的任何对象。对象主要由几何形状和材质构成。材质定义了对象的样式。我们可以通过编程来控制对象的位置，旋转和缩放。场景中添加的模型可以使用Three.js中的形状类，也可以使用JSON格式或二进制格式文件，也可以使用其它流行的3D建模工具（3DMAX、Maya）导出的obj文件，然后由Three.js的不同加载器对其解析。

（5）设置渲染器：三维空间里的物体映射到二维平面的过程被称为三维渲染。一般来说我们都把进行渲染操作的软件叫做渲染器[7]。具体需要生成渲染器对象、指定渲染器的高宽、设置渲染器的清除色等。通常设置好相机、添加完模型就可以调用渲染器的渲染函数来渲染整个场景了。

（6）设置交互：Web页面最终呈现模型，以及提供用户交互操作。良好的交互设计不仅能够吸引用户，增强用户体验，而且能够使用户对模型有更全面的认识。可以从三个技术模块进行设置：HTML5技术设计界面的结构、CSS技术对显示样式进行设定、DOMEvent处理鼠标键盘事件。

通过以上几个步骤，具有交互功能的三维模型就可以在网页上显示。图1为WebGL的绘图流程。

四、双节摆物理模型的设计与实现

双节摆模型是理论力学的一个基本模型，也是比较重要的一个模型。该模型的运动规律较为复杂，通过模拟双节摆的运动规律，能够使抽象的规律具体化和形象化。该模型主要是两根长度为L1和L2的无质量的细棒的顶端系有质量分别为m1和m2的两个球，初始状态如图2所示。我们将利用WebGL标准下的Three.js框架来模拟该模型从初始状态释放之后的两小球的运动轨迹。

1.双节摆物理模型的设计思路

首先对该模型进行功能分析，该模型需要实现改变两个小球初始位置或者质量观察两个小球的运动轨迹，并能够绘制两个细棒张力的变化曲线图，可以对各物理量变化情况如坐标、速度、能量等进行采集保存。基于以上功能描述，我们可以将本模型的实现归结为以下几点：

（1）画布、灯光、相机和渲染器等基本场景的设置；

（2）两个小球、细杆、固定点等初始状态绘制；

（3）运行过程中小球、细杆位置及变化曲线图的动态绘制；

（4）模型交互功能的实现（模型移动、旋转、缩放、参数改变、数据采集）。

本模型的关键是对小球进行受力分析以及运动轨迹的运算。在运动过程中忽略空气的阻力和细杆的质量。在整个系统中，不断变化的量是杆的张力、小球的速度、位置以及细杆的位置，而细杆的长度则是保持不变的。我们将固定点坐标设为（y，x，z），小球m1的坐标设为（y1，x1，z1），小球m2的坐标设为（y2，x2，z2），在处理小球速度时，我们将其分别沿着三个轴正交分解。

根据双节摆运动的速度、时间、细杆的张力以及系统的能量等来不断获得两个小球的坐标，从而在不同位置绘制小球和细杆来模拟其运动轨迹。细杆L1的绘制用绘制直线方法表示，通过固定点坐标和球m1坐标来确定，细杆L2的绘制通过球m1的坐标和球m2的坐标来确定。

2.双节摆物理模型的实现步骤

首先基于对模型的设计与分析，接下来开始模型的具体实现：

（1）基本场景设置

整个模型的绘制以及实现是基于Canvas画布实现的，Canvas元素有两个属性width和height来定义其大小。我们在Web页面中定义一个div元素，在JavaScript中通过id来获取该容器元素，随后引入Three.js库文件，通过WebGL渲染器来获得Canvas的上下文三维绘制场景。我们可以对renderer的尺寸、颜色等进行更加详细的设置，通过编写initCamera、initScene和initLight三个函数实现相机、场景和灯光的初始化。

（2）双节摆模型初始化设置

在整个模型绘制过程中，其工作主要分为初始化和运行两部分，分别由initObject和loop函数实现。我们将双节摆系统构建成Pendulum对象，主要包括支点对象（Cube）、小球对象（Ball）、细杆张力、长度、夹角余弦、系统能量等属性。小球对象包含的属性主要有质量、坐标和速度等，我们给这些属性设置一定的初始值，也可通过前端用户输入获得。通过封装对象的方式简化了调用过程，也便于灵活操作其相关属性，同时能够扩展相关属性。在创建物体时，需要传入两个参数，一个是形状（Geometry），本文用到的是立方体和球体，另一个是材质（Material），通过设置材质可以改变物体的颜色和纹理。

（3）绘制小球运动轨迹

小球运动轨迹的绘制主要是通过不断更新元素的状态位置等来实现动画。设置一定的时间间隔，不断获取小球的坐标，根据不同位置绘制小球，模拟出小球运动。通过编写loop函数来实现该功能，并调用如下代码实现小球的循环绘制。

window.requestAnimationFrame（） 是由浏览器专门为动画提供的API，该方法将告知浏览器要开始动画效果了，它在运行时浏览器会自动优化方法的调用，并且如果页面不是激活状态下的话，动画会自动暂停，有效节省了CPU开销。使用这个函数时需要在下次动画前调用相应方法来更新画面，这个方法就是传递给window.requestAnimationFrame的回调函数。通过递归调用同一方法来不断更新画面以达到动起来的效果。

在绘制细杆时我们使用new THREE.Line（）方法实时绘制，另外需要注意的是，在下次绘制之前需要清除本次绘制的细杆，调用scene.remove（）方法清除。为了使小球运动的轨迹更加符合运动规律，减小绘制误差，我们使用标准4级4阶的龙格库塔法（Runge–Kutta）[8]对小球位置和速度的微分方程进行高精度求解。

至此，双节摆的三维物理模型构建完成，我们需要调用Three.js库中的渲染器对整个场景和模型进行渲染，在渲染之前需要调用renderer的clear（）方法，来清除其颜色、深度和模板绘制缓冲区。随后该双节摆三维物理模型便可在Web上显示。为了能够使两个细杆的张力变化可视化，我们通过引入flotr2.js绘制两个细杆的张力变化曲线图。Flotr2[9]是HTML5绘制图表和图形库，它是一个独立框架，可以扩展，能够自定义图表类型，并且支持移动设备显示。

（4）交互功能实现

该模型对交互功能的实现主要包括三个方面：首先是参数的改变，在Web页面我们设置了可以让用户改变两个小球坐标位置和质量的输入文本框，用户可以输入不同参数以观察不同数据下小球运动的状态；其次是监听鼠标事件，主要包含mousedown、mouseup、mousemove和mousewheel等事件。这些事件是绑定在用于展示三维物理模型的div容器元素上。通过对这些事件的监听，模拟观察者，使用户能够将双节摆模型平移、旋转、缩放，以调整到自己喜欢和所需的角度或方式观看三维模型的每个局部细节；最后是数据采集和保存。在模型运行过程中，用户可以随时开始和暂停动画，我们使用的是按钮形式，有开始、暂停、继续和输出四个按钮。用户可保存任意时刻采集到的速度、张力和能量等数据，该功能利用HTML5新功能实现。

3.测试环境部署和运行

基于上述模型实现关键步骤和技术，我们实现了双节摆模型的构建。接下来需要对其进行部署和测试。WebGL对服务器端没有特殊要求，任意支持HTTP服务的Web服务器都可，我们将其配置在tomcat服务器上，接下来对其在不同操作系统、不同终端设备上进行测试。WebGL对硬件没有太高要求，CPU在1Ghz，内存在512MB以上即可。通过测试我们发现该模型可以通过PC端浏览器浏览，也可以通过手机、平板电脑等浏览器浏览，动画效果较为流畅，模型能够较为真实地模拟物理运动规律（如图3、图4、图5所示）。

五、总结与展望

1.总结

本文针对一般三维图形渲染过程中安装插件的麻烦，提出一种无插件的渲染方法，采用WebGL技术，三维模型可直接在浏览器端绘制和展现，无需安装任何插件。结合利用HTML5与WebGL相关技术，同时利用Three.js框架，在浏览器上构建出三维双节摆物理模型。通过测试实践，我们发现不管在PC端还是移动端，该模型三维动画的实现都较为流畅，在场景中能很好地通过鼠标或者触屏对模型进行移动、旋转、缩放等操作，从而实现多角度、细粒度的与模型进行交互，并且该模型能够进行相关数据采集和保存。研究结果表明，目前的主流浏览器都对WebGL都有较好的支持，这一技术的出现能够很好地解决跨平台问题。我们相信随着标准的进一步完善和相关技术的进一步推动，WebGL技术在网络交互、可视化及虚拟现实等领域都会有较大的推广价值，基于Web的3D仿真系统必将在商业、教育等领域有广阔的应用前景。

2.展望

开发基于WebGL的三维物理模型对开发建设移动学习资源的启示：

（1）开发移动学习资源是信息技术与教育教学深度融合发展的基本要求

教育信息化的大力发展，三通两平台的实现，新技术新媒体等的发展，教育信息化将促进教育的全面改革，建设移动学习新资源能为教师和学生开展移动学习、泛在学习提供可能，能更好的促进课堂教学方式的变革，促进学校的变革，也是促进信息技术与教育教学深度融合的基本要求。

（2）开发移动学习资源是变革教与学方式的基础

随着信息技术的不断发展，教与学也在不断的发生变化，移动学习资源的建设为开展信息化创新教学提供了有利条件，促进学生的知识建构，是更好地实施翻转课堂教学、开展创客教育的基础，也为学生开展泛在学习、移动学习提供方便。

（3）开发移动学习资源为智慧教育的实现提供可能

随着智慧教育的发展，人们对新型教与学资源的智能化需求越来越高，移动学习资源的智能化能进一步满足学生的个性化学习需求，促进学习者知识建构。建设新型优质教与学资源的共建共享，促进优质教育均衡化发展，进一步促进智慧教育的发展与实现。

当然，利用WebGL技术开发三维物理模型不是我们最终的目的，如何利用WebGL技术模拟演示物理现象及原理，将抽象的知识直观化、形象化，以激发学习者的学习兴趣和动机，并通过良好的交互设计来引导学习者进行知识的自我建构，能够给予学习者即时反馈是我们需要深入探究的重要课题。特别是处在移动互联网时代，如何利用这些技术创建出优质的移动学习资源，使学习者能够随时随地，更加灵活地利用技术进行学习是我们下一步研究的方向。我们有理由相信，随着技术的不断发展，必将推动教育融合创新，使教育更加开放灵活。

参考文献：

[1]艾达，乔明明，李敏等.Web 3D技术综述[J].微型机与应用，2014（2）：4-7.

[2]Wikipedia.WebGL[EB/OL]. http：//en.wikipedia.org /wiki/WebGL.

[3]祝智庭，孙妍妍.无缝学习——数字化学习新常态[J].开放教育研究，2015（1）：11-16.

[4]杨现民，李翼红.创客教育的价值潜能及其争议[J].现代远程教育研究，2015（3）：23-34.

[5]Khronos Group[EB/OL].http：//www.khronos.org/webgl.

[6]周敬敬，陈昕等.利用WebGL技术实现机房动态虚拟装配设计的可视化[J].科研信息化技术与应用，2013（2） ：87-92.

[7]况卫飞，彭四伟.三维渲染引擎编辑器的研究[J].电子设计工程，2009（9） ：91-92.

[8]陈哲.捷联惯导系统原理[M].北京：宇航出版社，1986：31-32.

[9]Flotr2 website[EB/OL].http：//www.humblesoftware.com/flotr2/.

基于模型软件开发 第4篇

关键词：敏捷开发,SCRUM,软件开发模型

1 传统软件开发模型

传统的软件开发模型有瀑布模型, V模型, 增量模型, 迭代模型, 螺旋模型, 快速原型模型等。其中瀑布模型是最早出现的软件开发模型, 1970年Royce提出, 直到80年代早期, 它一直是唯一被广泛使用的软件开发模型。瀑布模型的核心思想是将软件的生命周期分成可行性分析与计划、需求分析、软件设计、编码、测试及运营维护等六个阶段, 每个阶段按照线性方式进行, 当前阶段接受上一阶段的工作结果, 实施完成所需的工作内容。当前阶段的结果需要验证, 验证通过后, 该结果作为下一阶段的输入, 否则返回修改。此模型有很多变体, 例如V模型等, 但其典型性是只有当当前阶段的文档获得认可才可以进入下一个阶段。例如, 在开发初期制定详细的计划, 在计划中最终产品己被仔细研究, 并且拟定规模说明, 将一切详细资料都记录在案, 通过验证后需求分析才算结束, 然后进入下一阶段, 也就是设计阶段。传统开发模型的主要缺点有:

1) 其突出缺点是适应不了一直变化的客户需求。现实中的项目在进行时, 客户会不停的修改需求或者增加需求, 导致项目开发滞留在需求分析阶段, 无法有效地进入下一阶段, 最终导致产品被延期。

2) 传统开发模型的线性过程过于理想化, 早期的错误可能要等到开发后期才发现, 例如设计阶段发现需求的错误, 测试阶段发现需求或者设计的错误等, 特别是开发后期才发现需求的错误, 会带来非常严重的后果。

3) 客户在产品计划阶段提出需求后, 直到产品Alpha/Beta测试才能见到产品, 发现与预期的相差甚远, 提出大量的改进需求, 最终导致产品不成功或者被延期。

4) 传统开发模型的可行性分析与计划阶段要求明确需求, 从而制定产品的计划与进度表, 同时明确产品的成本及预算。但对于需求经常变化的项目, 该阶段的成果没有任何意义, 最终导致项目进度、成本等不可控。

2 SCRUM敏捷开发方法

敏捷开发是一种开发方法学, 可以应对客户快速变更的需求。它强调以人为核心, 采用迭代的方式, 循序渐进地开发软件。敏捷开发方法强调以人为本, 专注于交付对客户有价值的软件。在高度协作的开发环境中, 综合使用迭代式和增量式开发方法, 使用反馈来进行思考、反省与总结, 不断地实现自我完善, 从而达到软件的完美交付。

Scrum是被广泛使用的敏捷开发方法之一。Scrum是在十多年前由Ken chwaber和Jeff Sutherland博士共同提出的, 现在此方式已被众多大中小型企业使用, 其中包括摩托罗拉、谷歌、雅虎、微软、华为、思科、SAP、GE等。Scrum是一个敏捷开发框架, 是一个增量的、迭代的开发过程。在这个框架中, 整个开发周期被分成若干个小的迭代周期, 每个小的迭代周期称为一个Sprint, 一般最多以30天为一个周期。在Scrum中, 使用产品Backlog来管理产品或项目的需求, Backlog定义产品的所有任务, 包括功能性和非功能性的任务。在定义Sprint时, Scrum开发团队从产品Backlog中挑选最有价值的需求进行开发。Sprint中挑选的需求经过Sprint计划会议上的分析、讨论和估算得到一个Sprint的任务列表, 我们称它为Sprint Backlog。在每个迭代结束时, Scrum团队将产生可交付的产品增量。

Scrum定义的主要角色有:

1) 产品负责人 (Product Owner) :该角色负责产品的远景规划, 平衡利益相关者 (stakeholder) 的利益, 确定不同的产品需求和优先级等。它是开发团队与客户或最终用户之间的联络点。

2) 利益相关者/客户 (Stakeholder) :该角色与产品之间有直接或间接的利益关系, 通常是客户或最终用户代表。他们负责收集产品需求, 审查项目成果等。

3) Scrum负责人 (Scrum Master) :该角色负责指导开发团队进行Scrum开发与实践。它也是开发团队与产品拥有者之间交流的联络点。

4) 团队成员 (Team Member) :即项目开发人员。

Scrum定义的标准流程如下:

1) 根据客户需求, 定义产品功能列表Backlog以及每个功能的优先级。

2) 召开Sprint计划会议, 确立下一个Sprint的目标, 划分并确定这个Sprint内需要完成的任务, 标注任务的优先级并分配给每个成员。

3) 进入Sprint开发周期, 在这个周期内, 每天需要召开Scrum会议。

4) Sprint周期结束时, 召开Sprint成果评审会议, 将成果演示给产品负责人或者利益相关者。

5) 团队成员最后召开Sprint回顾会议, 总结问题和经验。

6) 这样周而复始, 按照同样的步骤进行下一次Sprint, 直到产品交付。

我们将在下一章节详细介绍大型项目中SCRUM的角色定义、软件开发模型及具体的开发流程。

3 基于Scrum的大型软件开发模型

3.1 角色定义

基于SCRUM的大型软件开发模型中的角色、文档及产品的对应关系如图1所示, 具体角色有:

1) 产品经理, 担任产品负责人的角色, 由开发方承担, 作为客户和开发团队的联络点。理解客户的需求及关注点, 创建和维护产品的需求清单Backlog, 并按照客户要求的优先级进行排序, 使得最重要的功能优先实现。产品经理还需要对每个Sprint的结果进行评审和审批, 并交付给客户。客户反馈的意见实时传达给开发团队, 并调整下个Sprint的Backlog。

2) 客户:负责收集编写产品需求, 审查项目成果等。他们通过产品经理来设定产品的期望, 传达产品的需求, 设置产品功能的优先级。

3) 项目经理, 担任Scrum负责人的角色, 负责指导开发团队进行Scrum的开发与实践。项目经理的主要职责有:

(1) 根据每一个Sprint的目标, 从产品Backlog中选择优先级最高的需求进行细化, 制定Sprint的Backlog;

(2) 召开Sprint计划会议、Sprint交付产品的评审会和客户反馈之后的回顾会, 并根据客户反馈调整下一个Sprint;

(3) 协助消除项目中的障碍, 维护障碍列表, 确保Sprint的交付;

(4) 敦促项目中依赖的解决, 维护依赖列表;

(5) 控制项目的风险, 维护风险列表;

(6) 培训团队, 提高生产力, 确保SRUM流程的执行;

(7) 评价项目过程的有效性、加强执行, 确保一切工作按照既定的规范来运行, 规划并进行必要的改进。

4) 项目开发组:产品交付要依靠团队的努力, 团队的职能是交叉的, 包含所有角色:开发人员、测试人员、系统环境支撑人员、文档编写、界面设计等人员。SCRUM团队是自我组织、自我管理的, 团队中的角色是不分等级、不固定职能的, 例如开发人员也可以做测试。

3.2 基于SCRUM的大型软件开发模型

为了提高开发的效率, 并提高产品的质量, 基于SCRUM的大型软件开发模型综合了传统瀑布模型、V模型等开发的优点, 在SCRUM开发流程中加了新的环节, 并对某些流程进行约束。图2为基于SCRUM的大型软件开发模型示意图。

SCRUM中每个Sprint周期的开发不是无序的。Sprint中每一个任务的需求是明确的, 建议使用瀑布模型、V模型或快速原型等进行开发。根据功能的大小及难易程度选择合适的开发模型。关键模块或者技术难点, 可以使用快速原型开发模型。较大的任务可以使用V模型, 测试人员可以从需求分析阶段就开始参与。较小的模块可以使用瀑布模型, 测试的工作等编码完成后才开始。这里的瀑布模型与V模型的开发流程, 尤其是文档的处理, 要比传统的开发模型简化了很多, 详细开发流程见下一章节。

在传统软件开发模型中, 大型的软件在功能测试和系统测试后, 产品要交付给客户进行Alpha测试和Beta测试, Alpha测试用于模拟环境下的测试, 有时候需要开发者在场。Beta测试用于在真实环境下的测试。Alpha测试和Beta测试后, 客户反馈测试结果给开发团队, 开发团队进行问题的修复或者功能的改进。Alpha测试和Beta测试对产品的质量至关重要, 我们将Alpha测试环节和Beta测试环节加入到SCRUM的开发流程中, 作为最终产品交付前的最后两个Sprint。

3.3 开发流程

3.3.1 产品Backlog的定义

产品Backlog是产品的需求列表, 列出需要产品的所有功能及优先级。产品Backlog是客户与产品经理共同制定的。客户通过产品需求规范、平台规范等文档的形式或者邮件、会议等沟通方式提出需求, 产品经理作为客户和开发团队的联络点, 理解客户的需求, 并进行梳理, 与客户共同制定产品Backlog, 包括:

1) 新的操作系统、新的平台等, 如Android平台

2) 功能方面的需求, 功能点

3) 非功能方面的需求, 如性能要求

4) 问题的修复与功能的改进, 如前面产品出现的问题

5) 每一个功能的优先级, 优先级反映客户的需求及关注点

产品Backlog在项目的过程中是不断完善的, 产品经理负责增加、删除、修改功能, 变更优先级等。在制定产品Backlog的过程中, 产品经理、客户及管理层、项目经理等及其他方需要举行一次或者多次的讨论会, 项目经理及项目开发团队对产品的需求列表的每一项都需要进行初步的可行性分析及工作量的估计, 精确的估计是在Sprint计划的时候给出。根据开发团队的预估计, 产品经理及客户初步确定产品的规模、Sprint周期数、产品预期的交付时间, 并根据需求的优先级, 初步确定每一个Sprint所完成的功能点。例如下图中产品Backlog, 1.1~1.3初步定在Sprint1中完成, 2.1~2.3初步定在Sprint2中完成。

3.3.2 Sprint Backlog的定义

在每个Sprint计划时, 项目经理根据本Sprint的目标及功能点的优先级, 从产品Backlog中挑选优先级最高的任务, 项目经理对这些任务进行细化, 开发团队对这些任务进行可行性分析及工作量估计, 确保在本Sprint的周期内能够完成。有时候挑选的任务较为复杂, 在本Sprint内不能完成, 产品经理、项目经理要对该任务进行分解, 并实时调整后期的Sprint。产品经理、项目经理及开发团队一起召开Sprint计划会议, 明确本Sprint的目标、周期长度 (起止时间) 、工作内容、分工、资源调度等。例如:

3.3.2 Sprint的开发

Sprint Backlog被确定后, 项目经理给每一个功能点指定开发者。项目开发者对每个功能点可以使用瀑布模型、V模型或者快速原型开发模型进行开发。如果使用V模型进行开发, 开发者可以定义需求文档、设计文档等, 测试人员也可以定义测试需求文档和测试用例设计文档。这些文档和传统的瀑布模型的文档不一样, 传统的瀑布模型、V模型中, 文档编写好后, 需要经过严格的审阅, 审阅修改完成后, 一般不能再修改, 即使后期要修改, 需要严格的流程。Sprint周期一般较短, 2周到1个月左右, 要完成V模型的开发, 需要快捷的流程及工具的支持。开发人员定义的需求文档, 侧重于需求功能的描述及对应的验证规范, 设计文档侧重于体系结构及外部接口等, 而且这些文档在后期的Sprint中可以更新的, 需要根据客户的反馈, 增加需求内容或者更新需求, 所以版本的控制非常重要。为了保证在该Sprint周期完成的功能复合规定的质量标准, 每一个Sprint周期测试人员都要参与。测试人员根据开发人员的需求与验证规范, 定义测试用例。功能开发完成后, 测试人员负责功能的测试。

3.3.3 Sprint的成果交付与反馈

每一个Sprint的可交付成果, 都要经过测试人员的严格测试。产品经理需要评审所完成的功能, 产品经理与项目经理、项目开发组一起召开评审会, 评审可交付的成果。评审通过后, 成果交付给客户, 客户就已经完成的功能进行试用或者评估, 并提出修改意见。产品经理将客户的改进需求及评估意见反馈给项目经理, 项目经理据此调整下一个Sprint的内容, 例如Sprint2原来定义如下:

根据客户反馈更新为:

对于Feature A1+, C1+, 我们将修改原来的需求文档和设计文档, 对于Feature D1, E1等, 和前一个Sprint的新功能类似, 需要进行需求分析和设计, 并生成需求文档和设计文档等。

3.3.4 Alpha测试与Beta测

产品所有功能完成, 交付版本给客户后, 客户进行Alpha测试。由于产品开发的整个过程中, 客户都见到产品, Alpha测试的反馈中, 客户需求的变更非常少, 更多的实际应用环境下问题的发现。Alpha测试的反馈, 作为一个新的Sprint, 该Sprint的Backlog列出所有的反馈问题, 团队开发的主要工作是问题的修复。修复完成后, 将产品交付客户进行Beta测试。Beta测试的反馈同样作为下一个Sprint的内容, 该Sprint完成后交予客户进行验收, 验收通过后, 产品进行发布。Alpha测试与Beta测试的两个Sprint, 需要在产品定义阶段进行定义, 客户也可以根据需要选择其中的一个或者全部。

4 小结

传统开发模型不能适应经常变化的客户需求, 而且客户在Alpha和Beta测试时才能看到产品, 如果产品与用户的预期相差甚远, 再提出需求更改已经太晚。而在SCRUM模型中, 每一个Sprint都产生可交付的产品, 客户可以见到产品, 及时校正自己的需求。对于需求不太明确或者经常变更的项目, SCRUM的优势更为明显, 越来越多的企业使用SCRUM来开发软件项目。对于需求明确的项目, 传统开发模型有质量控制的优势。该文提出的基于SCRUM的大型软件开发模型, 吸取了传统开发模型的优点, 并在开发流程中综合使用瀑布模型、快速原型、V模型等, 提高了产品开发的效率和质量。

参考文献

[1]Pete Deemer, Gabrielle Benefield, 使用Scrum的Agile (敏捷) 项目管理介绍, v1.04[Z].

[2]The official SCRUM rule book[EB/OL].http://www.scrum.org/.

探讨软件开发过程模型的发展论文 第5篇

0引言

从第一个软件开发过程模型一“瀑布模型”的产生到现在，人们陆续推出了许多软件开发过程模型11。这些软件开发过程模型是如何产生和发展的?软件开发过程模型还会发展吗?软件开发过程模型如何发展?研究这些问题对于推动软件工程理论向前发展具有重要意义。下面对这些问题进行研讨。

1对几个典型的软件开发过程模型的分析

下面分析几个典型的软件开发过程模型的产生情况，通过分析，既可以看到它们的内容又可以了解它们产生的原因。同时，也可以从整体上看到软件开发过程模型发展的大致过程，在此基础上思考软件开发过程模型的产生和发展问题。

1.1瀑布模型的产生情况

早期的软件开发活动带有明显的个体化特征，非常不规范，随意性很强，人们错误地认为软件就是程序，对程序之外的数据和相关的文档材料没有给予重视，对编写程序之外的软件开发活动(如需求分析、概要设计、详细设计、软件维护等等)没有给予重视，结果出现了软件危机。软件危机的典型表现有:开发成本急剧上升、开发进度一再拖延、软件难以维护甚至无法维护、软件质量无法保证、开发出的产品不能满足用户需要，等等。为了摆脱软件危机，人们开始研究软件开发方法，1968年提出“软件工程”的概念，主要思路是将人类从事各种工程项目积累起来的行之有效的原理和方法应用于软件的开发和维护活动中。在这种情况下，1970年瀑布模型被推出。

计划到开发成功、交删，再到废弃不用，有一个完整的生命周期，称为软件的生命周期。瀑布模型按照软件的生命周期，将软件过程分为:问题定义、可行性研究、需求分析、概要设计、详细设计、编码、测试、维护等几个阶段。软件开发活动按顺序一个阶段接着一个阶段地进行，每个阶段完成一项特定任务，每个阶段的结果经审查合格后方能进入下一个阶段。瀑布模型严格地规定了每个阶段必须提交的文档，强迫开发人员采用规范的方法，要求每个阶段提交的产品必须经过专家的仔细验证。这样，软件质量得到了保证。由于各阶段提交了规范的文档，软件维护变得容易一些。瀑布模型的成功在很大程度上是由于它是文档驱动的模型。

瀑布模型的推出，是人们为了摆脱软件危机迈出的重要的一步。按照瀑布模型去进行软件开发活动，克服了开发中的个体随意性和不规范倾向，使软件开发有章可循，有效地遏制了日益蔓延的软件危机。

1.2快速原型化模型的产生情况

按照瀑布模型开发软件，虽然很有效，但灵活性不强，因为瀑布模型是按阶段顺序来操作的，必须在前一阶段的工作完成后才能进行下一阶段的工作。需求分析是一个重要的阶段，由于在开发早期用户的需求往往是模糊的，或由于某些原因用户的需求要发生变化，导致需求分析阶段的工作无法结束，造成下一阶段的概要设计工作无法进行。这时如果继续采用瀑布模型进行软件开发活动，显然不妥，因此为了解决这类软件开发问题，必须构建新的软件开发过程模型。在这种情况下，快速原型化模型被推出。

人们认识未知的事物，往往按照“实践、认识、再实践、再认识，逐步完善”的规律去做，经过反复多次的迭代式的实践和认识过程，达到基本了解事物情况的目的。快速原型化模型按照这个规律进行软件开发活动，首先快速建立一个能反映用户主要需求的原型系统，请用户在计算机上试用，通过试用，用户提出修改意见;开发人员按照用户意见快速地修改原型系统，然后再让用户试用;然后开发人员按照用户意见再去修改;如此反复多次，直到原型系统完全满足用户需求为止。

采用快速原型化模型进行开发活动，有效地解决了用户需求模糊不清和用户需求不断变化的问题。可以认为快速原型化模型是对瀑布模型的补充和完善，瀑布模型是用静止的观点来看待软件开发活动，将用户需求看成是固定不变的，这样实际上是将用户需求简单化了，这种理想状态实际很难找到。快速原型化模型是从变化的观点来看待软件开发活动，符合客观型化模型的这种观点。

1.3增量模型的产生情况

采用瀑布模型或采用快速原型化模型来开发软件时，是按照模型规定的开发过程，完成各开发环节的所有任务，得到一个完整的软件，将其提交给用户。面对软件规模越来越大、软件市场竞争越来越激烈、用户要求越来越高的形势，这样开发存在很多问题。当你将一个大的.完整产品提交给用户后，用户要花费很多时间来学习这个新产品，短时间内很难适应这个新产品，给工作中应用该产品带来不便;这个产品完整提交后，用户再去评价和提出修改意见就没有意义了。这样，使开发风险加大，使开发时间增长，使用户满意度降低。为了解决这个问题，必须构建新的软件开发过程模型。在这种情况下，增量模型被推出。

人们解决大问题时，往往是将大问题分解为若干个小问题，每个小问题比较容易解决(其中有一个小问题是核心的关键问题)将这些小问题分别给予解决(对于核心的关键问题首先给予解决)，那么大问题也就被解决了。一般来说，分解出的每个小问题具有相对独立性，即每个小问题与其它每个小问题联系不紧密，这样，既可以一个接着一个地顺序去解决每个小问题，也可以同时去解决多个小问题。增量模型按照这样的方法进行软件开发，将一个大的软件分解为一系列较小的“增量”，每个增量分别进行开发，通常开发的第一个增量是软件的核心部分，实现软件的基本需求。向用户一个增量接着一个增量地分批提交软件产品。采用增量模型，用户从拿到第一个增量时开始，就可以学习和熟悉软件，通过使用来评价软件及提出修改意见;开发人员根据用户对已经提交的增量的反馈，可以改进软件产品。这样，提交所有增量后，软件产品就达到比较完善的程度，也提高了用户满意度。

1.4螺旋模型的产生情况

软件开发从始到终都存在着风险，项目规模越大、软件越复杂，开发该项目所冒的风险就越大。并且风险具有不确定性，可能发生也可能不发生，但是一旦风险变为现实，就会造成损失，甚至产生恶性后果。因此，如何识别风险、预测风险、驾驭风险，将风险可能造成的危害消除或减少，是软件开发中必须要考虑的问题。但是在螺旋模型之前所提出的各种软件开发过程模型，都没有强调“风险分析”。在这种情况下，螺旋模型被推出。

其实人们做任何事情之前，都要考虑风险。如果存在风险，那么一定要想办法去消除，否则成功希望渺茫。螺旋模型是在结合瀑布模型和快速原型化模型的发框架上，带有瀑布模型的系统性、顺序性和“边开发，边评审”的特点。螺旋模型也是一种迭代模型，每一次迭代均可采用快速原型化模型方法，每一次迭代均作风险分析。螺旋模型由若干个螺旋周期组成，每一周期都包括需求定义、风险分析、工程实现和评审四个阶段，当项目按顺时针方向沿螺旋线移动时，每迭代一次，螺旋线就前进一个周期，软件开发又前进一个层次，系统又生成一个新版本(即构造一个新的原型，这个新原型是在风险被排除后得到的)，当迭代过程进行到用户允许或可接受的范围时，迭代结束。

螺旋模型的推出，强化了人们的风险意识。通过使用原型来降低风险是一种行之有效的方法。螺旋模型集成了瀑布模型和快速原型化模型的优点，又有自身的特点，是一个实用性很强的软件开发过程模型。

1.5构件组装模型的产生情况

面向对象技术出现之前所提出的各种软件开发过程模型，一般很少考虑“软件构件”的重复使用问题，即使编程时重复使用了一些库函数，量也不大，并且粒度小。因此，软件开发的任何一项工作基本是从头开始做，完整地做到尾。这样开发的缺点是成本高、时间长，当然出错的可能性也大。这里的“软件构件”一般指源代码，现在将需求规格说明、用户界面、软件体系结构等等也作为“软件构件”。人们考虑:如果在开发新软件时，能大量地重复使用已经开发过的软件中的内容，开发时间和成本不就降低了吗?又由于已经开发过的软件经过了严格的测试，重复使用这些内容在质量上当然是有保证的。面向对象技术的出现，为这个想法开辟了道路。在这种情况下，构件组装模型被推出。

重复使用的思想早已在许多领域广泛应用了，例如在工业生产中，重复使用各种零部件来组装生产新产品。在软件生产中，由于每个软件与其它软件都不同，在面向对象技术出现之前，重复使用难度比较大。面向对象技术将数据和操作该数据的算法封装在一起，做成一个个的“类”，将一个或多个相关“类”组合成一个“软件构件”，在某领域内使用过的所有“软件构件”被放到一个“软件构件库”中，这样为重复使用打下了基础，构件组装模型就是通过重复使用“软件构件库”中的软件构件来进行软件开发。使用构件组装模型开发软件时，根据被开发软件的目标和开发方案，选取软件构件库中的软件构件，组装成一个完整的软件版本。

构件组装模型的推出，使前人的劳动成果被有效地利用了起来。按此模型进行开发活动，可以节省时现，使软件开发工作开始进入一个新时代。

1.6几个软件开发过程模型产生情况小结

从以上分析几个典型的软件开发过程模型的产生情况可以看出：软件开发过程模型的出现，是人们为了消除软件危机、使软件开发活动有序化和规范化、高效率地得到高质量的软件产品而不断研究总结的结果，每一种新的软件开发过程模型的出现，都为当时软件开发遇到的某一类问题提供了解决方案，从而丰富了软件工程的内容，推动了软件工程理论向前发展。

2.促使软件开发过程模型发展的主要因素

现在已经有了这么多的软件开发过程模型，软件开发过程模型还会发展吗?答案是肯定的。通过上面的分析过程和深入的思考，可以得出促使软件开发过程模型发展的两个主要因素：

第一，客观世界的情况在变化，不断出现新的问题，需要用计算机处理。面对新情况和新问题，原有的软件开发过程模型无法胜任，因此需要推出新的软件开发过程模型来处理新情况和新问题。回顾软件开发过程模型的变化和发展的历史，许多软件开发过程模型是为了处理新情况和新问题而推出的。例如快速原型化模型是针对用户需求不完整和用户需求不断变化的情况而推出的。例如螺旋模型是针对风险控制问题而推出的。例如文献[5]所介绍的建立在面向Agent技术上的Gaia模型，是针对现有的软件开发过程模型在开发复杂分布软件系统时常常遇到困难而推出的。例如文献[6]所介绍的一种基于Agent的自适应软件过程模型，是针对软件过程所处的环境发生变化问题而推出的。

第二，人们希望软件开发的效率更高、质量更好、速度更快，因此人们不会满足现状，势必要研究并推出新的软件开发过程模型。例如构件组装模型的推出，就是人们不满足现状、遵循“重复使用”的思想所推出的软件开发过程模型。再如文献[7]所介绍轻载(敏捷)软件开发方法中的XP模型(极限编程)，也是人们不满足现状，针对传统模型存在的问题，按照新的理念所推出的软件开发过程模型。以上两个主要因素显然会长期存在，因此软件开发过程模型必然还要发展。

3.软件开发过程模型如何发展

既然还会有新的软件开发过程模型被推出，就是说软件开发过程模型还要发展，因此人们要思考软件开发过程模型如何发展这个问题。根据对软件开发过间.降低成本，软件质量也有紙构件组装模型的出程模型有关情况的分析研究，软件开发过程模型可以

按以下三个方向去发展：

第一，可以通过对现有模型进行改进、扩充、综合去发展。

结合新问题的内容，针对现有模型存在的适用面窄、考虑问题欠周到等情况，可以通过改进和扩充某个软件开发过程模型的内容而得到一个新模型，或者通过综合运用几种软件开发过程模型的内容而得到一个新模型。如文献[8]介绍的一种新的软件开发过程模型，是在瀑布模型基础上进行改进和扩充的结果。再如增量模型，是综合运用瀑布模型和快速原型化模型的结果。再如文献[9]介绍的一种新的软件开发过程模型，是综合运用瀑布模型和构件组装模型的结果。再如文献[10]介绍的一种新的软件开发过程模型，是综合运用构件组装模型和并行过程模型的结果。

第二，软件开发过程模型可以遵循新的思维方式去发展。

现有的软件开发过程模型，每一个都体现出各自不同的思维方式，例如瀑布模型是所有采用线性思维方式模型的典型代表，快速原型化模型是所有采用反复循环迭代思维方式模型的典型代表。遵循新的思维方式去发展，就是说，新建立的软件开发过程模型应该是新的思维方式的体现，即按照新的想法去组织软件开发活动。例如XP模型(极限编程)就是按照新的思维方式去发展起来的。从Agent具有自主性、反应性、社会性等角度看，各种面向Agent的软件开发过程模型都是按照新的思维方式发展起来的。

第三，软件开发过程模型可以借助新技术和新工具去发展。

任何软件开发过程模型都是建立在一定的技术和工具基础之上，技术和工具的进步对软件开发过程模型的影响是巨大的，当新技术和新工具出现后，传统的开发方式势必要被改变，所以说新技术和新工具会推动软件开发过程模型更新发展。如构件组装模型、基于体系结构的软件开发过程模型，就是在面向对象技术基础上发展起来的。再如RUP[12]模型，就是在UML这个开发工具基础上发展起来的。

4 结束语

基于模型软件开发 第6篇

【关键词】ABAQUS软件；负压创面治疗技术；负压封闭引流装置；有限元

【中图分类号】R722.12【文献标识码】B【文章编号】1005-0019（2015）01-0514-01

负压创面治疗技术（negativepressurewoundtherapy，NPWT）是近二十年来提出并开展的新方法，1993年德国外科医师Fleischmann[1]等最先提出的封闭负压引流（vacuumsealingdrainage，VSD）。1994年，裘华德[2]等引进德国NPWT应用于普通外科手术及感染创面的治疗。1997年美国外科医师Argenta和Morykwas[3，4]首创的封闭负压辅助闭合（vacuumassistedclosure，VAC）。近年来，创面封闭负压引流技术被广泛的应用于各种皮肤软组织缺损创面的治疗之中，关于负压引流技术的机制的研究也在不断深化。我们应用ABAQUS软件建立了负压引流装置的有限元模型，并通过它来研究负压引流装置工作状态下形变程度及创面上个点的压力分布情况。

方法

1、由武汉维斯第医用科技股份有限公司提供型号为VSD-D-2的负压引流装置，实测其敷料大小为15×10×1cm。

2、在ABAQUS软件中，因为模型与荷载都是对称的，根据对称性，取模型的一半来模拟，在part模块中，通过extrusion方法建立一个50mm×150mm×10mm的三维变形体。同样的方法，再建立引流导管。在property模块中，分别建立名为fuliao和daoguan的材料，并为问题描述的数据设置相应的参数。分别设置名为fuliao和daoguan的section，并赋予相应的区域。之后在assembly模块中进行装配，建立相应的instance。

定义分析步，在step模块中建立两个类型为soils的瞬时分析步，第一个荷载步名称为load，在这一步中施加荷载，为了模拟荷载的瞬时增加，将荷载步的时间取为1s，并在随后的边界条件设置中将该荷载步下顶部设置为不排水。时间增量步采用自动搜索功能。第二个荷载步名称为consolidation，在这一步中孔压消散进行分析，随后的边界条件设置为排水，该步长总长3天，时间增量步采用自动搜索功能。

因网格质量的需要，将模型沿着管剖开分为12块。进入mesh选项将环境栏的object选项选为part，即网格划分是在part层面上进行的。将单元大小设置为2.5，导流管截面按数值划分为12份。单元类型为C3D8P（P代表孔压单元），网格共计6240个单元。模型敷料表面施加大气压强。模型顶部固定，不排水，同样不透水，敷料表面贴近皮肤处位移自由，且是自由排水面，敷料底部管口处完全透水。在initial初始分析步中对模型顶面及四周设置相应的位移边界条件，即模型顶部固定三个方向的约束，四周仅能允许微量竖向位移，在consolidation分析步中将底部管口处的孔压边界设为零。进入job模块，建立任务，设定所加负压为0.04MPa，提交计算。

结果

成功建立负压引流材料的有限元模型，输出如图1所示。

图1：施加负压为0.04MPa时，负压敷料形变图及孔压云图。左图绿色部分所示为负压敷料发生形变后情况，箭头所示为引流导管所在位置，右图为孔压云图。

讨论

临床常用的负压为0.04MPa，这种负压状态下大部分创面渗出液能被及时吸引出，能提供一个较好的负压环境，促进基地肉芽生长。在计算中，我们设定所加负压为0.04MPa进行计算，可以很明显的看出，导流管附近的压力较小，体现了组织液向管中的渗流，但是因材料特性的影响，敷料内部压力值基本不变。即负压范围在0.04Mpa时，敷料内部压力比较平均。由文章开头处可知，管口处孔压无限接近零，导流管中有负压，由孔压云图可以看出敷料内部各个地方受负压的影响情况。图例所示，右图中深蓝色为负压值最大的区域，浅蓝色负压值次于深蓝色，整块敷料大部分呈深蓝色和浅蓝色，负压存在且部分区域负压较大，渗出液能被顺利吸出，液体流动较为顺畅，与实际情況相符。

结论

负压封闭引流装置的有限元模型能较好的模拟其实际工作状态下的一些物理参数，可借助有限元模型协助研究负压封闭引流装置对于创面各处的压力变化、渗出液引流情况的影响的问题。

参考文献

[1]FleischmannW，StreckerW，BombelliM，KinzlL（1993）Vacuumsealingastreatmentofsofttissuedamageinopenfractures.Unfallchirurg96（9）：488–492.

[2]裘华德.负压封闭引流技术[M]，北京：人民卫生出版社，2008：72-116.

[3]周常青译.美国负压创面治疗技术[M]，北京：科学技术文献出版社，2005：1-2.

基于DIMINE软件地质模型建立 第7篇

1 矿床地质概况

沙溪铜矿床为热液型-斑岩型铜金矿床。其中, 某矿段矿体主要产出去复背斜东翼, 矿体分布长约1000m, 水平宽约600m。本矿段矿体由9条勘探线53个钻孔控制, 矿体主要赋存在石英闪长斑岩岩体内, 少量赋存在岩体上接触带泥质粉砂岩中, 形态较为稳定。Ⅲ号矿体为本矿段最大的主矿体。

矿体呈现较复杂的形态, 剖面上总体呈不规则的似层状、透镜状, 矿体头部和尾部经常有分叉现象, 水平中段及纵剖面上呈哑铃状。矿体总体走向15~35°, 矿体倾向南东东, 倾角25~55°左右, 多在40~50°, 矿体少量由于脉岩的侵入破坏, 以及含矿岩体本身矿化不均匀, 局部存在少量夹石。矿体顶板最高标高-136.9m, 底板最低标高-941.42m。

2 地质数据库的建立

2.1 原始数据收集及整理

收集对所有原始资料, 主要是钻孔和坑道等探矿工程数据, 提取见矿的探矿工程数据。根据平剖面图, 核对孔口坐标、钻孔深度、测斜数据、样品数据的信息, 重点查看钻孔深度要不小于测斜深度的最大值很取样位置的最大值, 编制对应的孔口表、测斜表、样品表。根据DIMINE数据表格识别格式, 将表格保存为txt或csv文件。

数据库数据主要包括上述三个表, 各表所包含的内容见下表1:

2.2 地质数据库的建立

将之前讲的三个表导入DIMINE软件, 另存为DIMINE软件数据表格, 作为建立地质数据的的数据源。在此工程中, 需对数据表格进行检测, 生成检测报告。运用生成的三个表文件, 生产钻孔DMD模型, 并转化为DMG文件。如图1所示:

2.3 数据库的更新与展示

钻孔数据会随着探矿工作的不断进行而不断增加, 所以钻孔数据库需要不断完善、不断更新。DIMINE软件能够迅速实现钻孔数据库的合并和录入, 满足数据不断更新的要求。此外, 该数据库还能进行编辑、查询、统计分析及三维可视化显示操作, 能更直观的显示钻孔数据信息与矿体之间的关系, 并能通过不同的颜色段来显示品位分布情况。

3 三维模型建立

3.1 矿体模型的建立

该模型的建立是三角面片模拟矿体的三维空间的展布形态。为了满足实际运用的需求, 所建立的三维模型需要与地质队所提供的报告相符合。因此, 本次采用提取平剖面矿体边界线圈连矿体的方法建立三维矿体模型。在模型的建立过程中, 发现通过对剖面线框建立的模型后期检验, 对模型切各个中段平面图时, 与地质报告CAD图存在较大偏差。考虑到剖面间的矿体连接不可控性, 在圈连矿体时, 加入各中段平面矿体轮廓线共同约束创建模型。按照勘探网度, 加入相同间距的平面图, 满足控制程度。最后, 对矿体模型进行有效性检测, 进行优化, 删除多余的多段线和保持面片方向一致, 直至达到要求。建成的三维矿体模型为矿体的空间展布提供更直观的认识。

3.2 块段模型的建立

为方便对三维矿体模型进行品位估值和储量计算, 需要对矿体模型用一定规格的小立方体模拟其形态, 我们称此模型为块段模型。利用钻孔数据库, 能对块段模型每个小立方体估值, 进而计算矿体的储量。

①立方体尺寸的确定:理论上来讲, 小立方体的尺寸越小, 计算越准确, 但是计算机处理数据增多, 所需时间更长。所以, 综合考虑矿山勘察网度、开采最小单元、品位变化情况等因素, 确定小立方体的内外尺寸均为4×4×2m。

②估值方法与椭球体的确定:估值方法通常有两种, 一种是距离幂, 一种是普通克里格。由于钻孔数据偏少, 不满足变异函数分析;并通过对两种方法的估值结果进行对比, 相差很小, 本次就采用比较简单的距离幂的估值方式。估值所用的椭球体参数由矿体的走向、倾向、厚度和三个方向的长度确定。本此采用的椭球体参数为100×0.6×0.4。

3.3 块段模型品位估值

对之前的地质数据库进行样长组合, 并利用矿体模型约束, 对矿段模型进行品位估值。估值后的块段模型表示了矿体的品位分布, 能利用不用颜色区分高低品味分布, 更直观地为采矿设计提供依据 (图2) 。为了在采场矿量计算中简单区分矿石与废石, 先将矿体模型添加属性类型并赋值为“0”, 定义为废石, 待估值完用, 用矿体对矿体模型进行约束, 然后再将属性赋值为“1”, 定义为矿石, 这样在计算时, 在分类计算中可以计算范围内的矿石与废石的量。

4 储量计算

根据估值好的块段模型, 对矿段某矿体进行储量计算并统计分析。将统计结果与矿山地质报告储量进行对比, 可以看出模型计算出的储量与传统地质方法计算的储量基本吻合。地质储量的相对误差为-1.4%, 在不同方法计算储量的允许误差范围内。实践证明利用DIMINE软件建立三维模型计算储量比较准确, 误差控制在允许范围内。这方面DIMINE软件已经取得了储量司的认可。表2为某矿体三维模型计算储量与传统地质储量数据的对比情况。

5 结论

自动化、智能化已成为矿山发展中的一个必然趋势。做好三维模型是建设智能化矿山的重要环节, 现代化技术革新的迅猛发展, 使的三维数字化成为可能。DIMINE软件结合了地质、测量、采矿等核心专业, 在矿山行业得到广泛使用。

沙溪铜矿为斑岩型铜矿床, 具有储量大、品位低、夹石多等特点。所以开采过程中需要更准确的地质数据作支撑。DIMINE软件作为一个三维数字软件, 提供更直观、准确的模型数据, 结合沙溪铜矿独特的模型构建方法, 提高矿体模型的准确性。依托建立的地质模型, 完成后续的设计工作, 缩短设计周期, 使人力资源得到高效利用。

参考文献

[1]王李管, 贾明涛, 曾庆田.数字矿山整体实施方案及其关键技术[J].采矿技术, 2006, 6 (3) :493-498.

[2]王李管, 何昌盛, 贾明涛.三维地质体实体建模技术及其在工程中的应用[J].金属矿山, 2006 (2) :58-62.

基于模型软件开发 第8篇

基于模型驱动的汽车电子软件开发流程可以分成五大步骤, 包括分析需求、设计系统、生成代码、集成软件以及标定系统。上述步骤实际上都是围绕模型系统进行的, 而且合理形成V字形状。分析需求就是说利用需求模型来适当地描绘系统想要达到的目的, 分析需求的时候主要有两项工作为需求建模以及需求验证;设计系统实际上是依据分析需求来深入设计系统, 从而可以发现符合系统需求的方案, 包括两方面工作即设计模型和验证模型;生成代码就是利用设计系统过程中有机的结合产生的配置文件、系统模型以及基于模型驱动汽车电子运行平台自动形成代码;集成软件就是把自动形成的代码分别合理地形成不同的软件平台, 然后利用一定软件部署策略来形成统系统;标定系统是开展汽车电子软件独特的项目, 需要相关参数配置, 合理匹配特定车型和软件, 因此, 也是指导软件开发的主要系统[1]。

开发软件主要可以分为应用开发和平台开发两大部分。开发应用主要就是从设计模型开始的, 利用需求模型来合理的分析和验证模型。模型验证和需求建模是反复互动的过程, 验证结果能够发送到设计模型中, 作为模型修改的依据。经过验证没有问题的模型会被变换为高层次系统模型, 也就是构件系统模型或者系统层系统模型。在深入设计系统模型的时候, 需要验证完成设计的系统模型, 验证结果对于进一步开发具有直接作用, 为调整和修改模型提供依据。在完成验证模型以后, 需要依据模型系统和模型需求来配置特定平台。配置的根本目标就是制定和裁剪系统平台, 配置结果需要与模型系统形成系统代码。经过编译之后的自动生成代码可以应用到系统中。现阶段, 仅仅只能应用原型系统, 需要经过检验之后才能够使用。在模型系统的指挥下测试系统, 此外, 可能需要修改测试系统。一旦进行修改系统就进入到模型系统阶段, 需要进一步开发。基于模型驱动的汽车电子软件开发方式包括算法组建和应用构件。算法组建是能够进行独立算法的通用模块。算法组建是通过很多函数共同组成的, 完成设计算法的组件可以合理的运用到平台算法库。应用构件是独立通用应用模块, 例如, 电子油门构件[2]。通用构件在完成设计以后需要适当的引入到平台构件库中, 需要复用相关应用。系统平台主要包括算法组件库、应用构件库、驱动库等。在系统生成的时候, 需要依据文件的配置系统来合理的选择和配置系统平台库的内容, 然后合理的运用到应用系统中。

2 模型驱动的汽车电子软件关键技术

2.1 强实时微内核操作系统技术

开发电子汽车软件的主要特征就是把操作系统引入到开发中。在以前传统的开发方式中, 主要重视控制系统开发的策略, 导致操作系统变得可有可无, 但是伴随着电子汽车软件变得更加复杂, 使得在开发的时候操作系统变得更加重要, 一些开发方式可以把操作系统合理的引入到开发中, 但是只是作为基本支持平台, 主要有依据操作系统进行设计和验证。但是汽车电子软件的开发方式合理的把强实时微内核的操作系统引入其中, 以此当做设计系统开发的核心, 并且依据系统对平台进行代码生成和验证, 所以, 在汽车电子软件开发中, 基于驱动的开发模型不再仅仅是可选部分, 而是成为开发的主要部分[3]。

2.2 系统运行分析技术

基于模型驱动的汽车电子软件开发的方式中, 系统运行分析是验证模型的重要方式。系统运行的分析主要就是利用分析模型, 模拟动态行为, 以此来检验是否具有符合规范的模型设计。

2.3 图形化设计技术

表达模型的主要形式就是图形, 也是UML建模的重要语言特点, 可以图形化需要表达的数据信息, 但是需要一定的工具来进行图形化支持。Smart C是一种不仅可以表达图形, 也可以表达文本的建模语言, 但是也需要一定的图形化工具, 支持把数据进行图形化, 所以, 想要开发基于模型驱动的汽车电子软件就需要开发能够支持图形化的工具。因此, 可以适当使用eclipes平台以及相关能够进行图形化的插件来当做开发的平台和方式, 从而可以开发基于模型驱动软件的相关图形化工具[4]。

2.4 自动生成技术

想要增加软件开发的质量和效率主要方式就是自动生成技术, 在基于模型驱动汽车电子软件开发中的自动生成技术主要包括自动生成程序代码、自动生成系统模型以及自动生成设计文档。自动生成系统模型实际上就是说由高层次模型形成低层次模型, 例如把系统系统需求模型变换为系统设计模型。自动生成设计文档实际上就是根据系统设计模型来形成相关设计文档, 此时需要合理分析模型, 能够在模型中提取语义, 并且依据相关格式规范需求利用自然语言进行表达。自动生成程序代码实际上就是利用系统的配置文件和设计合理的把预制程序代码形成组合实际系。预制代码主要包括各种驱动、操作系统等代码以及各种复用的构件。此外, 在使用自动生成技术的时候, 需要保持具有同步的生成目标和生成源, 例如, 变动程序代码可以适当地引发设计模型的改变, 利用一定的同步技术, 可以尽可能地降低设计系统反馈时间, 从而可以增加开发效率[5]。

3 结束语

总而言之, 基于模型驱动的汽车电子软件的开发, 能够很好地融合模型驱动开发方式和模型设计软件方式, 并且提出了合理的设计方式, 从而可以很好地解决汽车电子控制系统的可靠性, 对于汽车行业的发展以及经济发展具有很大影响。

参考文献

[1]杨国青.基于模型驱动的汽车电子软件开发方法研究[D].浙江大学, 2010.

[2]杨帆.汽车电子软件的实时性验证方法研究[D].湖南大学, 2011.

[3]高志刚, 吴朝晖.汽车电子软件中混合调度方式下响应时间分析[J].中国机械工程, 2011, 19 (17) .

[4]伍如意.基于AUTOSAR标准的汽车电子软件开发平台分析和设计[D].浙江大学, 2011.

基于系统调用的软件行为模型研究 第9篇

入侵检测指的是在一个系统中, 检测异常行为的能力, 而这种异常行为通常是由安全攻击, 病毒和软件设计缺陷所引起的。目前主要有两种途径进行入侵检测, 一种是基于网络的入侵检测, 另一种是基于主机的入侵检测技术, 而基于主机的入侵检测技术又分为基于用户行为的和基于软件行为的入侵检测检测技术。

1软件行为及隐马尔可夫模型的研究

1.1软件行为模型研究

程序在正常情况下和在异常情况下运行, 系统调用序列会产生偏差, 可以在很大程度上体现软件的行为特征, 因此, 可以利用系统调用来研究软件的行为特征。最早的动态建立的软件行为模型是Forrest提出的N-gram模型。在这个模型中, 他用若干个长度为N的系统调用序列, 来描述一个软件的行为。

1.2隐马尔可夫模型

在马尔可夫链中, 每个状态都和一个观测事件一一对应, 也就是说可以直接观测到状态。隐马尔科夫模型 (Hidden Markov Model) 则是在马尔科夫模型中发展而来, 它的观测值和状态不是一一对应, 能够描述更为复杂的问题, 它通过一些概率分布来表示模型特征, 是一个双重随机过程。

2软件行为模型改进

2.1基于频率的子序列抽取算法

N-gram是自然语言研究领域广泛使用的一个概念, 它表示的是长度为N的字符序列。在计算机系统中, 每个系统调用都有一个对应的编号, 随着程序的运行, 会产生一个系统调用序列。每一个长度为N的系统调用序列, 就称为一个N-gram。

基于频率的序列简化算法其核心思想就是:从原有序列中抽取出一些子序列, 这些子序列的出现频率较高 (具体的频率要求根据实际需要可做适当修改) , 然后用这些子序列的编号替换原有序列中的子序列, 从而得到一个更加精炼的序列, 并且保持原有序列中元素的先后关系。

下面具体阐述基于频率的序列简化算法, 为了描述方便, 首先定义几个变量:

Ck表示长度为k的序列集合, 即k-grams。

Cki表示长度为k的序列集合中第i个元素。

Ckif (s) 、f (Ck) 、分别表示这些序列的出现频率。

该算法用伪代码描述如下:

2.2基于系统调用的隐马尔可夫模型改进

为了能够更加准确的描述一个软件的行为, 扩大输入数据的覆盖率是非常重要的, 也就是要尽可能多的让获取到的系统调用序列覆盖全部的程序执行路径, 获取系统调用序列是尽量让软件进行不同的操作。

假如经过序列简化算法化简后的系统调用序列是{ (1) (2) (3) (4) (5) (6) (7) (8) (9) }, 这就作为隐马尔可夫模型的观察值了。假定计算机就两种状态:安全和不安全, 这作为隐马尔可夫模型的状态集。所以前向变量αt (i) 表示在给定模型参数λ (A, B, π) 下, 出现观察序列为O1, O2, O3…Ot, 并且t时刻的状态为i的概率。例如α4 (安全) 表示在给定模型参数λ (A, B, π) 下, 出现系统调用序列为 (1) (2) (3) (4) , 并且在4时刻为安全状态的概率。后向变量βt (i) 表示在给定模型参数λ (A, B, π) 和t时刻状态为i的条件下, 后续观察序列为Ot+1, Ot+2, Ot+3……OT的概率大小。例如β4 (安全) 表示已知模型参数λ (A, B, π) 和t时刻状态为安全, 后续观察序列为 (5) (6) (7) (8) (9) 的概率大小。

在前向后向算法中, 必须借助上述前向变量和后向变量来定义另外两个用来做似然估计的变量和, 分别为3.1式和3.2式,

和的大小范围都是0到1。

γt (i) 表示给定观察序列和模型参数λ, t时刻为状态i的概率大小。例如γ4 (安全) 表示已知观察序列为 (1) (2) (3) (4) (5) (6) (7) (8) (9) 和模型参数λ, 在4时刻计算机为安全状态的概率大小。式子中分母的作用是确保

3软件行为模型验证

3.1实验过程

本章将从实验的角度, 选取Gzip (GNU Zip) 工具软件作为实验对象, 利用在上一章中实现的系统对改进后的行为建模方法与原来的软件行为建模方法进行一个对比, 从而达到论证新的模型构建方法高效性的目的。

具体的实验步骤如下:

(1) 首先开启Ftrace工具对系统内核的监控, 再操作Gzip软件, 在linux操作系统上进行各种操作, 例如压缩解压缩等, 并且这些操作必须保证都是合法的。

(2) 然后关闭Ftrace工具, 保存好Ftrace工具监测得到的trace报告文件。重复上述步骤200次, 总共可以可到200条软件行为轨迹。

(3) 接着拿50条系统调用序列分别用原隐马尔可夫模型和改进后的隐马尔可夫模型进行软件行为模型的建立。

3.2实验结果

从图2的模型生成时间比较图中, 可以很清楚地看见, 新的软件行为模型的构建方法比传统的只用隐马尔可夫模型构造软件行为模型要高效, 并且随着初始软件行为轨迹的增多, 即系统调用序列的增长, 这两种方法所花时间的差距越来越大

4总结

虽然软件行为的概念定义很早就出现了, 但真正定量的形式化描述一直都是研究热点, 并且至今没有很好的成果。利用统计学中的隐马尔可夫模型来建立软件行为模型, 时间代价太大。本文改进了这种建立软件行为模型的方法, 缩减软件行为模型的生成时间。并通过实验, 证明了改进后的软件行为模型生成方法相对于原有方法, 能更快速的生成模型, 并且基本保持原方法的高准确率。

参考文献

[1]李珍, 田俊峰, 杨晓晖.基于系统调用属性的程序行为监控[J].计算机研究与发展, 2012, 49 (8) :1676-1684.

[2]陶芬, 尹芷仪, 傅建明.基于系统调用的软件行为模型[J].计算机科学, 2010.

[3]王新平, 顾庆.基于执行轨迹的软件缺陷定位方法研究[J].计算机科学, 2009, 10 (36) .

基于模型的软件测试的研究 第10篇

软件测试通过设计和执行测试用例, 来判断被测系统 (System Under Test:SUT) 的实际行为和预期行为是否一致, 从而检测软件内部缺陷。大量文献表明通过科学合理的软件测试, 可以大幅度提高软件质量、增强用户信心。基于模型的软件测试方法从抽象的形式化模型中自动生成测试用例并予以执行。模型往往采用形式化描述, 从而自动生成测试用例, 但实践表明必要的手工也不可或缺。根据上述描述, 模型必须比SUT更为简单、更易于检查、修改和维护, 否则, 测试模型的开销将会与测试SUT的开销相一致。但模型也必须保证一定的精确度, 保证可以依此产生有用的测试用例。

2、相关概念及基于模型的测试过程

本文中测试用例集代表测试用例的一个有限集。其中测试用例是输入和预期输出构成的结构体:在一个确定的变化系统中用输入和输出对表示, 在一个确定的反馈系统中用输入和输出构成的序列表示, 在一个非确定的反馈系统中用树或图来表示。

目前, 基于模型的测试过程一般包括如下步骤:

步骤1:依据需求或规约生成SUT模型。该模型包括了预期行为, 该行为根据需要可采用不同的抽象级别。最抽象级别可能将每个可能的输入映射到"无异常"或"不崩溃"之类的输出。

步骤2:定义测试用例选择标准。好的测试用例往往可以检测出严重失效或可能失效。但上述的定义不具有可操作性, 在实际实践中, 测试选择标准可能与一个系统拥有的功能相关 (例如基于需求的测试选择标准) , 可能与一个模型的结构有关 (例如状态覆盖、transition覆盖和def-use覆盖) 等。

步骤3:将测试用例选择标准转化为测试用例规约。测试用例规约对测试用例选择标准予以形式化并使之具有可操作性。

步骤4:一旦模型和测试用例规约生成后, 将产生测试用例集。

步骤5:一旦测试用例集产生后, 开始执行它。

注意在测试过程中模型和SUT处在不同的抽象级别, 我们必须采用适配器模块在两者之间建立桥梁。判断 (verdict) 用于比较SUT输出与测试用例提供的预期输出的区别, SUT的输出必须被抽取出。Verdict可以采用如下结果:通过、失败和未知。其中通过代表预期输出与实际输出一致, 失败意味着不一致, 未知意味着无法做出判定。

3、分类

本文通过七个维度对基于模型的测试方法进行描述, 并对每一个维度探讨了可能取值。

3.1、模型主体

模型主体包括SUT模型和SUT所处环境模型。目前基于模型的软件测试中往往两者都同时考虑。SUT模型的作用包括 (1) 作为SUT的oracle (因为SUT包含了预期行为) (2) 利用结构信息产生测试用例。SUT所处环境模型用于限制SUT模型的可能输出。

3.2、模型冗余程度

基于模型的测试可以被应用到不同的场景。大致说来, 主要区别在用于测试和用于实现的模型间的冗余程度。文献[4]中描述了两个可能场景。第一个场景中模型被用来同时产生测试用例和系统实现。该场景中用于产生代码的模型必须描述详细, 但对测试用例生成来说确需要抽象级别更高的模型。第二个场景是:模型仅用于产生测试用例, 该模型根据规约文档生成, 而SUT则是手工实现。我们可以使用该模型作为系统的规约补充, 但其相当复杂, 往往需要补充文档辅助才能使用。

3.3、模型特征

模型特征与非确定性、时序问题、模型的连续性或事件离散性有关。非确定性在SUT和模型中均会发生。时序问题一般与实时系统相关。而就动态性而言, 模型可能是离散的、连续的或两者综合。基于模型的软件测试过去往往关注离散模型, 但连续或者混合模型目前在嵌入式系统中得到广泛使用和研究。

不同的模型特征将影响对模型表示法的选择、测试用例的生成和执行。

3.4、模型表示法

目前存在大量模型范式对SUT进行建模, 根据[5]获得如下的分类:

(1) 基于状态的表示法:针对变量集和修改变量的操作对系统进行建模, 变量集代表系统内部状态的一个快照, 操作通过前置条件和后置条件定义。典型代表为Z、B、VDM和JML。

(2) 基于Transition的表示法:描述不同系统状态间的transition。采用类似FSM的形式进行表示, 结点代表系统的状态, 边代表系统的操作或行为。目前常通过添加数据变量、采用分层的机器和机器之间的并行来加强表示能力。典型代表为Statecharts, labeled transition system和I/O automata。

(3) 基于历史的表示法:通过描述随着时间的推移, 行为允许的轨迹对系统进行建模。可以使用不同的类型的时间记号 (离散或连续, 线性或分支, 点或区间等) , 导致了不同类型的时序逻辑。

(4) 函数表示法:将系统描述为数学函数集, 有可能是一阶的也有可能是多阶的。但该类表示法较为抽象和难于使用, 所以在基于模型的测试中使用并不多。

(5) 操作表示法:认为系统是可执行进程集, 进程间并行执行。该表示法适合描述分布式系统或通讯协议。典型代表是进程代数或者Petri net。

(6) 随机表示法:通过基于事件或者输入值的概率模型来描述系统, 更倾向于为环境建模。例如使用Markov chain为期望的用户操作版本建模, 据此产生的测试用例集可以体现用户的实际使用场景。

3.5、测试用例选择标准

测试用例选择标准可以辅助测试用例的生成。目前并不存在一个最优标准。普遍使用的标准包括:

(1) 结构化模型覆盖标准:标准充分利用了模型结构信息, 例如在基于transisiton的模型中, 采用与图相关的覆盖标准来生成测试用例。

(2) 数据覆盖标准:标准主要关注如何从大规模数据空间里面选择典型取值。常见的方式是等价类划分和边界值分析。

(3) 基于需求的覆盖标准:当模型的元素与SUT的非形式化需求相关时, 需要基于需求的覆盖标准, 例如:需求数量可能与UML状态图的transition有关。

(4) Ad-hoc测试用例规约:除了模型, 测试工程师可以依据经验, 用形式化的表示方法编写必须覆盖的测试用例规约, 指定对应的测试用例。

(5) 随机标准:大部分用于环境模型, 因为是环境决定了SUT的使用方式。行为概率直接用模型表示。产生的测试用例反应了用户的实际操作情况。

(6) 基于缺陷的标准:适用于SUT模型。最常见的基于缺陷的覆盖标准是变异覆盖。包括对模型进行变异、产生测试用例用于区分变异模型和原有模型。

3.6、测试用例生成技术

目前在给定SUT模型和测试用例规约下, 主要包括如下技术:

(1) 测试用例随机生成:采用随机游走的方式从系统的输入空间随机采样, 但可能导致每次生成的测试用例集拥有不同的特征, 目前常常将随机游走与用户操作版本相结合。

(2) 专用的图搜索算法:包括结点覆盖、边覆盖算法。

(3) 受限的模型检验:用来确认或者证伪一个系统的属性。对于特定的属性, 如果属性不满足的时候, 模型验证将输出一个反例。

(4) 符号执行:它采用符号 (如变量的名称) 而不是实际的值来代表系统的输入。作为结果, 执行过程中系统所有的变量及输出为符号或关于符号的表达式。

(5) 演绎定理证明:与模型验证相似, 用定理证明器代替了模型验证器。一般用来检查公式的可满足性。

3.7、联机/脱机测试用例生成

主要关注测试用例产生和执行的时机。在联机测试用例生成时, 测试用例产生算法可以依据SUT的实际输出予以调整, 这在SUT是非确定的时候是必要的。脱机测试用例生成意味着测试用例在生成结束后才能执行, 脱机测试的一个优势是测试用例易于管理, 因为测试用例变动较小。并且可以尝试采用最小化方法对测试用例规模进行缩减。

4、小结

目前存在大量的基于模型的软件测试方法和工具, 包括LEIRIOS Test Generator (LTG) 、AETG、JUMBL等。相信本文将有助于研究人员理解基于模型的测试方法的优点和不足, 并更好的将这类方法应用到现实的软件开发过程中。

摘要：基于模型的软件测试根据被测系统模型和所处环境模型生成测试用例。本文讨论了基于模型的测试过程, 并从7个维度进行初步探讨。相信本文将有助于研究人员了解基于模型的测试方法的优点和不足, 并更好的将这类方法应用到现实的软件测试过程中, 提高软件质量。

关键词：软件测试,模型,测试用例规约,测试用例选择标准

参考文献

[1]、W.Prenninger, A.Pretschner, Abstractions for Model-Based Testing, ENTCS 116 (2005) 59-71.

[2]、A.Pretschner, W.Prenninger, S.Wagner, C.K¨uhnel, M.Baumgartner, B.Sostawa, R.Z¨olch, T.Stauner, One evaluation of modelbased testingand its automation, in:Proc.ICSE'05, 2005, pp.392-401.

[3]、S.R.Dalal, A.Jain, N.Karunanithi, J.M.Leaton, C.M.Lott, G.C.Patton, B.M.Horowitz, Model-based testing in practice, in:Proc.ICSE'99, 1999, pp.285-294.

[4]、A.Pretschner, J.Philipps, Methodological Issues in Model-Based Test-ing, in:[29], 2005, pp.281-291.

软件工程方法模型浅析 第11篇

关键词：软件开发模型； 瀑布模型； V模型； 迭代模型

中图分类号：TP311 文献标识码：A 文章编号：1006-3315（2014）09-120-001

一、前言

当今时代，软件的重要性与日俱增，从办公生活到休闲娱乐，日常生活中每时每刻都有软件的身影。企业要提高运作效率，家庭要提升生活质量，电商要提升营销精准度；政府要提升公众满意，无不需要依靠各种各样的软件。CRM、ERP、大数据、互联网APP，各式各样的软件正在改变着我们的生活，我们已经进入一个软件定义世界的时代。

在此背景下，软件开发也变得越来越至关重要，而作为软件开发管理的基础，软件工程方法的正确选择和应用将是软件开发项目成功的保障。

本文主要简要探讨一些常见的软件工程模型方法及其适用范围。

二、瀑布模型

瀑布模型（Waterfall Model）是最早出现的软件开发模型，在软件工程中占有重要的地位，它提供了软件开发的基本框架。该过程由一系列顺序的活动构成，每个活动分为输入、过程与输出三部分。其中上一项活动的输出被作为本活动的输入，利用这一输入实施该项活动应完成的内容，最后给出该项活动的工作成果输出，作为下一项活动的输入。

从上述描述中我们能够看出，传统的瀑布模型具有如下的优点：

（1）为项目提供了按阶段划分的检查点。使得软件开发过程从无序变为有序，使软件开发的工程管理变为可能。

（2）各项活动串行进行，当前一阶段完成后，只需要去关注后续阶段。软件工程管理变得简单清晰。

（3）它提供了一系列的模板，这个模板使得分析、设计、编码、测试和支持的方法可以在该模板下有一个共同的指导。

瀑布模型也存在如下致命缺点：

（1）各个阶段的划分完全固定且周期较长，极大地降低了开发效率。

（2）由于开发模型是线性的，用户只有等到整个过程的末期才能见到开发成果，从而增加了开发风险。

（3）项目管理更加注重过程，而容易忽视对目标及价值结果的关注。

（4）无法应对开发过程中出现的用户需求的变化。

（5）开发与测试活动割裂，导致测试人员天然的依附于开发人员。

综上，典型的瀑布模型相对来说比较理想化，适合那种开发周期固定、客户需求清晰的项目，当前几乎被业界抛弃，很难适应当今软件开发的需求。比如互联网应用软件很难使用瀑布模型来管理。

三、V模型

V模型一定程度上是典型瀑布模型的一种改良，可视为瀑布模型的延伸。主要是针对开发、测试活动割裂进行的改良。把测试设计工作提前到分析、设计、编码各阶段，一方面提升了开发效率，同时开发与测试同源，提升测试有效性。

典型的V模型开发流程包括：需求分析（系统测试分析）、概要设计（集成测试分析）、详细设计（单元测试分析）、编码、单元测试、集成测试、系统测试和发布。和瀑布模型的最大区别是测试设计分析的提前，比如单元测试分析。在瀑布模型中，单元测试是在编码后进行的，输入的是编码；而测试人员需要根据编码先设计单元测试用例，然后执行。这样将存在一个风险，即单元测试只能发现编码本身的问题，即使编码完全未按照详细设计进行，单元测试也无法发现。而在V模型中，开发人员、测试人员针对详细设计展开工作，开发人员编码的同时，测试人员编写单元测试用例，从而使得测试用例不受具体编码影响，能够更加准确的验证详细设计的意图。其他阶段类似。

V模型中，测试活动有更多的独立性和自主性，软件开发效率也有一定程度的提升。但是V模型无法解决瀑布模型的本质缺陷，如同样无法应对需求的不断变化，同样需要在版本开发后期才能验证成果等。

三、迭代模型

早在20世纪50年代末期，软件领域中就出现了迭代模型。通俗的讲，迭代模型就是将整个软件的开发分解成一个个的子特性开发（阶段），而针对每个阶段内部采用的还是类似瀑布模型的方法。每个迭代是一次完整的经过所有工作流程的过程：需求、分析设计、实施和测试工作流程。每一次的迭代都会产生一个可以发布的产品，这个产品是最终产品的一个子集。

与传统的瀑布模型相比较，迭代过程具有以下优点：

（1）由于每个迭代是整个系统的子系统，相对内容比较单一，各个阶段需要传递的信息量较小，不需要通过大量的文档进行传递。

（2）由于整个开发过程被拆分为独立的若干阶段，用户在每个阶段结束就可以提前看到开发成果。一方面能够及时对开发中出现的偏差进行纠正；另一方面由于能够及时看到工作成果，有利于开发人员的效率提升。

（3）相对于瀑布模型，迭代模型更加关注对软件目标、结果的关注，更加注重和最终用户的互动，以保证开发成果的质量。

（4）由于用户的需求并不能在一开始就作出完全的界定，它们通常是在后续阶段中不断细化的，而迭代模型更能够适应这种需求的变化。

同样，迭代模型也存在其缺点，那就是对于项目经理和开发团队的要求更加高，并且需要团队成员之间更加的信任。因为迭代模型运作对于过程的监控较弱，更加关注面对面的交流与合作。

四、结束语

软件工程方法包含的内容很多，除了正确的选择模型方法以外，还包括各种能力域的工程方法，如计划管理、资源管理、财务管理、人员管理、价值管理、需求管理、风险管理等等。只有根据软件项目具体的情况和目标，选择正确的工程方法模型，并把这一系列的工程管理方法有机的结合起来，才能使得软件开发的结果可预期，质量可保证。

参考文献：

[1]软件工程-实践者的研究方法，（美）Poger S.Pressman

[2]钱乐秋.《软件工程》[M]北京：清华大学出版社，2005

基于VB的通用运动控制软件模型 第12篇

通用运动控制平台是近几年来运动控制系统经常采用的一种实现平台,其基本结构是工业PC加运动控制卡形式,这种平台的优势十分明显,既保证了运动控制的实时性,又能够提供强大的任务层规划执行能力和人机交互性能,而且还可以简化系统设计,降低开发和维护成本,因而是目前流行的运动控制解决方案[1]。系统软件的开发包括人机界面、运动控制、流程控制、网络通讯等多种功能,工作量比较大,难度相对于机电系统的开发人员而言也是比较大的。因此简化运动控制软件的设计,设计通用的运动控制软件模型,甚至设计可重用的运动控制软件模块,就显得非常必要。

VisualBasic(VB)是微软推出的面向Windows的可视化编程开发工具。其开发过程具有开发周期短、门槛低、易学易用等优点,在机电系统软件开发方面占有很大的比例。VB也存在着一些缺点,例如缺乏稳定的应用框架,运行的稳定性较差,实时性较差,不支持完全的面向对象技术等。但这些问题一部分可以通过合理的编码来解决,另外的则可以通过合理的建模与技术手段来解决。

本研究将基于VB和开放式运动控制系统,提出新的运动控制软件模型,并结合VB分析其实现所需的关键技术。

1 运动控制软件模型设计

基于PC的运动控制软件的开发通常是采用运动控制卡附带的驱动程序和开发函数库(API),利用现有的各种通用编程语言和开发环境进行软件的开发,其功能模块与结构如图1所示。

为了简化运动控制软件的开发,本研究提出了如图2所示的软件系统模型。该模型基于面向对象的方法建立,用UML[2]中的类图(ClassDiagram)表示。

下面对该模型做一简要的说明。整个系统模型由3部分组成:(1)运动模型部分,包括类Motion,Axis和Coord,以及相关的辅助类,例如实体类Point,Trajectory和配置类MotionConfig、AxisConfig和CoordConfig等;(2)事件模型部分,包括类Event和EventListener;(3)任务管理模型,包括类Task和TaskMan。

1.1 运动模型设计

运动模型是对运动的封装,该模型将运动系统的运动分解为单轴的运动、轴的随动和多轴同步运动。在本模型中将单轴的运动通过类Axis实现,将多轴同步运动通过类Coord实现。轴的随动是指一根轴跟随着另外一根轴(主轴)按照某种规律运动,例如电子齿轮、电子凸轮等运动模式,这种运动模式的特点是只需要进行配置,配置完成后该轴将自动地随着主轴的运动而运动,无需单独控制,因此没有设计专门的对象来完成该运动的控制。随动运动的配置是在Motion类中实现的。

类Motion是对运动的整体封装,对外部提供统一的调用接口。应用程序通过调用Motion类中的方法来实现对运动的控制,而类Motion则将相应控制命令转发到类Axis和Coord来实现。此外,类Motion还负责运动系统的初始化、参数配置、事件处理等工作。在实现方式上,类Motion除了对随动控制的配置外,其余均是通过调用类Axis和类Coord的方法实现;而类Axis和类Coord则是通过调用运动控制卡API来实现的。这样设计的优点是当底层运动控制元件改变后,运动控制模块对外的接口(类Motion中的方法)可以保持不变,只需更改Axis和Coord中方法的实现即可,保证了本模型的重用性。

所有的运动控制系统的参数都保存在配置文件中,通过调用类的初始化函数完成运动系统硬件的配置过程。同时该模块中的类都是有状态(state-machine)的,在不同的状态下允许调用的方法是不同的,保证了运动控制系统软件调用的安全性。

1.2 事件模型设计

运动控制系统作为典型的机电系统,要求软件能够及时地响应突发的事件,尤其是在运动过程中触发的各种事件,例如运动停止、伺服报警、行程开关触发等。由于VB中对对象技术支持的不尽完善,无法通过对象运行时类判别获得事件的类型,必须设计统一的事件处理模型。在本研究的模型中,事件的处理采用了“监听器”模式,由运动类产生事件,监听器类获取事件,并通知应用程序处理。其模型如图2部分所示,其实现方法说明如下:

在VB中事件对象可以直接用类模块来定义,在运动过程中产生异常时,运动模块只需生成一个Event对象,将运动状态信息写入到事件对象中,然后调用监听器的事件接收方法将该事件传播出去。事件监听器获得事件后,利用RaiseEvent语句产生一个VB事件,并将Event对象作为VB事件的参数。这样,在包含事件监听器对象的应用模块中就可以像处理普通VB事件一样对该运动事件做出响应。

(1)Motion类中addEventListener()方法的实现。

VB里有一个集合对象Collection,可以实现对EventListener的管理。其代码如下:

该代码实现了将事件监听器与运动控制对象的关联。

(2)事件的传递。

当运动模块检测到运动信息后,调用sendEvent()方法来送出事件:

1.3 任务管理(多线程)模型设计

Basic语言本身不支持多线程技术,VB虽然可以通过调用Windows的API来实现多线程[3],但该方法难度较大。考虑到本研究中的控制模型主要利用线程进行运动状态监视,运行时间短,因此,本研究提出了基于定时器的多线程模型,其采用分时的思想,如图2中左下部分所示,包括类Task和TaskMan。

该模型的工作原理如下:当定时器产生定时器事件时,对象TaskMan调用schedule()方法,在该方法中,根据任务队列中的每个任务的优先级(priority),运行周期(interval)等数据,依次调用Task对象中的run()方法,从而模拟了多个线程运行的效果,如图3所示。

应用程序只需要实现Task对象中的方法,就可以编写自己的多线程应用。在编程中需注意run()方法中的代码应尽量做到高效、执行时间短。由于Windows操作系统和VB中定时器的限制,其执行周期最小也需54.9ms,只能应用到实时性要求不高的场合。如需使用更高精度的时间间隔,应当使用Windows中的多媒体定时器,能实现最高1ms的调用周期。

在基于PC的运动控制系统中,当运动出现异常时,运动控制卡能自动进入保护状态,因此对软件处理的实时性要求不高,基于定时器的多线程模型能够满足控制软件编程的需要。

2 模型的实现

2.1 类的定义

VB 6.0提供了类模块(ClassModule)[4],可以用来实现模型中定义的类。本研究所建立的运动控制系统模型对类没有特殊的要求,因此可以直接在VB中定义(如图4所示)。

2.2 运动类的实现

前面介绍了运动类的接口,该接口可以很容易地利用各种运动控制卡所提供的API实现,在本系统中,所使用的是固高科技提供的GT400系列的通用运动控制卡,该卡提供了Windows平台下的C开发库和VB开发接口。由于该卡提供了Axis和Coord的工作模式,这两个类可以很容易地直接利用运动控制API实现。本研究重点说明了类Motion的实现方法,包括初始化过程、运动监视过程等。

初始化时,类Motion首先根据配置文件获取每根轴的配置信息,然后调用类Axis的方法,创建Axis对象,初始化Axis对象,并执行Axis对象的AutoHome方法进行零点标定。当所有轴都初始化完毕后,再根据配置文件中的坐标系信息调用GT400的函数以创建Coord对象,并初始化,然后分别根据配置文件中的电子齿轮和电子凸轮参数配置Motion类中的电子齿轮和电子凸轮参数。这些配置操作可以通过直接调用GT卡的驱动程序实现。

上述初始化过程完成后,最后一个步骤就是初始化监听进程,可利用上述多任务模型实现。在监听进程中,利用GT提供的API,就可以读取轴状态字和坐标系状态字,并进行分析,可提取出相应的运动状态,然后利用事件模型将状态传播出去。监听进程初始化结束后处于停止状态,当类Motion处于运动状态时才会启动。

2.3 配置文件的格式

在本研究中,配置文件采用XML格式,并给出了运动控制系统所需要的所有配置参数,下面给出一个配置文件供参考:

3 模型的应用

由于该运动控制软件模型采用面向对象技术来设计和实现,因此能够很方便地和应用系统软件结合起来。本研究将上述模型用于“基于计算机视觉的大幅面丝网网版检测装置”的控制软件的开发中,取得了很好的效果。其软件设计模型如图5所示。

装置工作原理如下:由于丝网网版幅面较大,采用运动机构驱动数字相机分块扫描并判别的方法,当相机运动到某个预定位置时,开始采集图像,并进行匹配和识别,与此同时相机向下一位置运动,直至整个网版全部被处理完毕。由于检测精度较高,对运动系统的运动精度要求也较高,较高的定位精度有助于提高图像定位和匹配的速度。

在本软件系统中,Motion模块作为底层的模块出现,为其他各个模块提供运动信息,并接受主程序模块MainApp和人机界面模块UI的运动控制命令。UI模块启动Motion模块按照规划好的路径运动,并随时处理Motion模块的事件消息,显示在操作界面上;图像处理模块Image需要从Motion模块中获得当前的位置信息,以便于进行图像的定位和匹配操作。所有的模块由主程序MainApp调度,例如当运动控制模块达到指定位置后,调用图像处理模块采集图像,并启动图像处理线程。为了提高图像处理的速度,Image模块采用VC编程实现,以DLL的形式封装[5],并提供接口供VB调用。

4 结束语

VB是基于Windows的一种简单易用的开发环境,是比较适合作为机电软件开发人员使用的一种开发工具,本研究所建立的运动控制模型及其基于VB环境的实现具有较好的通用性,可以直接应用在一些一般的通用运动控制系统上。

由于采用了面向对象的模型,该软件模块也具有较强的扩展性,开发人员可以根据具体的应用,开发出不同的接口,从而实现不同的功能。

摘要：针对通用运动控制系统控制软件开发中存在的复用问题,结合VB开发环境在机电系统软件开发中的优缺点,提出了较为通用的运动控制软件模型及其实现方法,重点分析了基于VB平台开发此类控制软件所需要解决的关键技术问题及其解决方案,包括事件处理机制、多线程机制模拟等,并结合具体应用分析了该模型的使用方法。研究结果及应用分析表明,所提出的基于VB的运动控制模型适合大多数开放式运动控制平台,所采用的方法和技术对其他工业应用软件的开发也具有一定的参考价值。

关键词：Visual Basic,运动控制,软件建模

参考文献

[1]吴宏,蒋仕龙,龚小云,等.运动控制器的现状和发展[J].制造技术与机床,2004(1):24-26.

[2]高焕堂.UML嵌入式设计[M].北京:清华大学出版社,2008.

[3]周丹,邬义杰.多线程技术在开放式CNC系统中的应用[J].机电工程,2003,20(4):68-71.

[4]张少伍,韩江,胡慧萍.基于VB的数控车削加工仿真系统的研究与开发[J].机电工程,2007,24(11):35-36,52.