软件特征（精选7篇）
软件特征 篇1
0 引言
开源软件也称为开放源代码软件, 是一类遵照开源软件许可证发布的软件, 具有源代码完全开放的显著特征。随着计算机技术的发展和应用普及, 开源软件已经成为当前计算机软件的重要组成部分, 逐渐形成了以软件技术服务为主的开源软件商业化模式, 是未来软件开发及应用产业发展的核心方向之一。相比商业软件, 开源软件的特殊性主要体现在遵照开源软件协议和源代码完全开放两个方面, 由此造成了很多不确定性, 例如开源软件协议的法律效力问题、著作权及权属约定问题和软件源代码潜在的侵权及专利风险问题等[1,2]。
在开源软件知识产权法律研究方面, 张平、张韬略等从开源软件本体对知识产权制度的影响分析, 认为开源软件自身的特殊性与现有知识产权保护的封闭性趋势有所冲突, 这一冲突是产生开源软件知识产权问题的核心[3,4]。另外一些研究者针对具体涉及的法条解释和司法案例分析等, 系统论证了开源软件的知识产权法律适用性, 分析了现有版权制度和专利保护在调整开源软件过程中存在问题[5,6,7,8,9,10]。其中, 穆合义等通过分析开源软件许可证, 归纳了许可证契约下的软件特征[9]。闫晔等针对基于开源软件开发专有软件这一具体问题开展版权保护研究, 提出通过著作权和专利权共同保护的方法规避侵权风险[10]。
综上所述, 由于开源软件是一类法律意义上的新鲜事物, 现有法律的滞后性可能会制约其发展, 相关知识产权法律法规适用性和使用过程中存在的潜在风险及规避方法是当前研究的热点。同时, 由于开源软件涉及程序代码和软件开发等计算机技术, 其专业技术特征非常明显, 也给知识产权法律工作者和研究人员带来了困难和挑战。针对开源软件知识产权相关的专门性单一法律适用性特点和法律特征, 例如单独针对著作权法或针对专利法, 需要进一步深入地梳理和分析。
著作权法保护在计算机软件相关知识产权保护中处于核心地位。开源软件作为一类计算机软件, 其著作权优先得到保护。同时, 其开放的源代码及软件开发的无限继承性所带来的著作权风险及矛盾调整问题也是首当其冲的, 例如著作权的归属问题与变更调整, 软件代码修改和再次发布等源代码继承过程中的侵权风险等。本文将针对开源软件的著作权法律适用性问题, 依据著作权法和相应法律法规, 归纳开源软件的著作权属性和法律特征。
1 开源软件历史与基本概念
1.1 开源软件发展历程
尽管开源软件一词最早出现在1998 年, 但是开源理念可以追溯到20 世纪80 年代的自由软件运动。1984 年, 美国Richard Stallman发布了《GNU宣言》, 反对当时逐渐流行的封闭软件源代码行为, 倡导发起自由软件运动。随后, 广泛用于自由软件及后来的开源软件的通用公共许可证 (即General Public License, 缩写为GPL) 正式发布。1989 年, 芬兰赫尔辛基大学Linus Torvalds发布了具有里程碑意义的Linux操作系统软件。Linux采用GPL, 为开源软件兴起提供了基础核心支撑。1997 年, 美国Eric Raymond在著作《The Cathedral and the Bazaar》 (中文版为《大教堂和大集市》) 中进一步明确区分了自由软件和商业软件, 理论性地论证了自由软件以及后来的开源软件在开发模式上代表着历史发展和技术进步的必然趋势, 为后续开源软件的发展进行了关键的理论探索。
1998 年2 月3 日, “Open Source”被正式提出用于开源软件, 以区别自由软件。接着, 由Eric Raymond等人发起并设立了开源计划组织 (Open Source Initiative Association, 简称OSI) , 为开源软件发展提供了有效的组织支撑和制度保障。1999 年初, 《Open Sources: Voices from the Open Source Revolution》 (中文版为《开源软件:开源革命之声》) 正式出版。至此, 开源软件的指导思想、发展思路和系统性概念及理论体系初步形成, 成为有理论、有目标、有框架、有内容、有权威组织负责机构的完整体系。目前, 开源软件正处于快速发展阶段。我国于2004年成立了中国开源软件推进联盟, 随后出现了开源中国社区等组织。各组织持续推动着开源软件发展。一些研究机构和企业致力于开源软件的开发和应用, 取得了一些成果, 例如红旗Linux和优麒麟Ubuntu Kylin等。
从软件开发自身及商业化发展角度来说, 开源软件不同于自由软件, 它在坚持开放、自由和共享的同时, 充分发挥自身特点和技术优势, 积极与商业市场充分融合, 逐渐实现了产业化发展。随着基于开源软件的信息技术服务业和软件公司逐渐壮大, 市场占有率不断上升, 已经初步形成了开源软件的商业产业链。另外, 大型商业软件公司也找准时机, 纷纷与开源软件组织展开合作。例如, 1999 年, IBM率先启动开源软件支持计划, 与开源社区组织合作, 共同开辟了新型的以服务为盈利的商业模式。总之, 从软件开发目标和理念来看, 开源软件继承了自由软件精神, 通过软件的开放、自由传播和共享, 实现软件和知识的全人类共享。开源软件的商业模式为其提供了无限的发展动力。尽管自身特殊性和法律滞后性给开源软件发展带来了隐患, 但是, 开源软件是未来软件发展的重要趋势, 其前景不可估量。
1.2 开源软件定义与开源软件许可证
通过OSI的说明可以发现, 开源软件定义本身是对开源软件许可证所做的界定。具体来说, 任何一款软件或程序只有采用了OSI认证通过的开源软件许可证进行发布, 该软件或程序才能够归属为开源软件。其中, OSI开展认定所依据的开源软件许可证认定标准是核心。该标准文件限定了开源软件许可证的基本条款和要求内容, 从而约束了开源软件的发布、开发和使用等各项工作, 其内容主要包括确保软件可以被自由的再次分发, 发布的软件必须包括源代码, 保障使用者可以修改并开发获得衍生版本的权利, 保障作者源代码的完整性, 以及应用对象不得有歧视及其他限制等。目前, 通过OSI认证的开源软件许可证约有近30 多种, 例如常见的LGPL、MPL、BSD、QPL和IBM等许可证。
通过上述标准认定的软件许可证才能称为开源软件许可证或协议, 并可以被用于开源软件的发布。尽管各种开源软件许可证存在或多或少的差别, 但是其基础标准已经被严格限定。由于其所采用的协议严格遵守相应开源软件许可证标准, 因此, 开源软件特殊性的根源来自于此。这类开源软件协议的约束为软件本身带来了众多显著特征, 并与其他类别软件存在明显差异。典型的具体特征包括: (1) 必须遵守预先约定的开源软件许可证即开源软件协议; (2) 源代码完全开放; (3) 软件作者保留相应著作权; (4) 软件作者对软件后续责任的免除; (5) 后续再次发布等过程中的开源协议继承性。这些特征突出表现在协议约束继承性、代码完全开放性和担保责任免除性等三个方面, 并对著作权相关权利属性产生影响。
2 开源软件的著作权属性
开源软件属于计算机软件的一个分类。在保护开源软件时, 会适用保护计算机软件的制度。自20世纪60 年代以来, 世界一直在探索调整计算机软件的法律制度。1972 年, 菲律宾成为世界上最早选择使用版权法来保护计算机软件的国家。1980 年, 美国也将计算机软件纳入版权法的调整范围。1990年, 我国颁布的《著作权法》第三条将“计算机软件”纳入著作权的保护范围。1994 年, 关贸总协定乌拉圭回合通过了《与贸易有关的知识产权协议》, 其中规定了计算机软件应作为《伯尔尼公约 (1971 年) 》所指的文字作品给予保护。目前, 我国的计算机软件相关知识产权法律法规除了《著作权法》外, 还包括专门的《计算机软件保护条例》。
计算机软件著作权主要保护内容为著作权人申请保护的程序源代码和相关的文档。而从著作权保护内容来看, 其保护的核心主体是“表达”, 并不保护所谓“思想”的技术核心, 计算机软件也是如此。尽管在现有知识产权保护方法和专业技术上, 无法通过简单地审核程序代码和文档进行“技术”甄别, 以实现软件“思想”的保护, 但是, 由于计算机软件不同于文字或艺术作品, 是为解决计算机运行等实际技术问题而开发的, 具有明确的实用技术性质, 因此, 单纯基于软件版权和著作权法保护知识产权存在潜在风险。
使用著作权法保护计算机软件是目前国际通用做法。依据我国《著作权法》和《计算机软件保护条例》规定, 计算机软件著作权人拥有法律规定的专有权利, 包括发表权、署名权、复制权、发行权、出租权、修改权、翻译权和信息网络传播权等。另外, 软件著作权人还有权将署名权之外的其他专有权许可他人使用并获得报酬。软件著作权人可以将全部或部分权利转让出去获得报酬。此外, 著作权人还可以为了保护自己的权利附加技术措施或权利管理信息, 其他人不得故意规避或破坏。著作权法在授予和保护著作权人权利的同时, 也做出了一定限制, 主要体现在保护时间、附件合法持有者额外权利以及研究学习等合理使用约束。
开源软件作为一类特殊的计算机软件, 虽然具有众多差异性特征, 但是其仍然受版权法规制。开源软件的作者同样享有以上著作权, 其权利也受到著作权法的限制, 只不过权力与限制所表现的内容和调整对象不同而已。与传统计算机软件相比, 由于开源软件其本身所依赖的开源软件许可证协议及其固有的合同约定效力, 开源软件在著作权方面存在一些差异性, 其法律特征主要体现在放弃部分权利和约束附加义务, 比如, 开源软件开发者明确放弃复制权和修改权。但这些不影响开源软件受到著作权法的保护, 根据著作权特点, 开源软件著作权人享有的具体权利项可以主要分为精神权利、财产权利和作品附加管理信息及措施受保护权利三个方面。
3 开源软件著作权内容
3.1 精神权利方面
开源软件著作权的精神权利方面是指开源软件著作权人基于开源软件而依法享有的与其人身密切相关的权利。所涉及的精神权利包括发表权、署名权、修改权及保护作品完整权。
发表权是将开源软件公之于众的权利。一般来讲, 开源软件在未发表之前的软件本身是私有软件, 只有按开源许可证协议要求发表以后才可以说是开源软件。开源软件普遍采用网络社区发布方式, 对于在社区公布于众的代码, 其代码的提交可以认为是发表。
署名权是开源软件开发者表明身份以及在软件上署名的权利。通常将开源软件作品上署名的人推定为开源软件作品的作者。开源软件的开发主要由开源软件网络社区组织、企业或自然人完成。对于变更协议发布的软件作者, 其署名权不会因为将软件开源而丧失对软件的所有。对于开源软件作者来说, 署名权所代表的精神权利意义十分突出, 并明确加以保护, 以防他人假冒署名。大多数开源软件许可证明确要求修改者必须说明具体修改内容, 并注明软件原作者, 确保不影响原作者的声誉。
修改权是指对开源软件代码或文档进行增加、删除或变更程序语句前后顺序的权利。开源软件修改权与一般软件不同。如果开源软件修改后不再发布, 这种修改是没有限制的。如果是对开源软件修改后再发布, 则应严格遵从具体开源协议, 该制约来自协议的合同效力。
保护作品完整权是指保护开源软件不受歪曲、篡改的权利。对于开源软件的任何修改, 都需要明确原作者并标注修改内容。由于软件产品不同于文学艺术作品有强烈的人格色彩, 所以其主要内容完全可以被包含在修改权内。这项权利也包含防止恶意修改的作用。
3.2 财产权利方面
开源软件的财产权利包括复制权、发行权、出租权、信息网络传播权、翻译权及应当由开源软件权利人享有的其他权利, 包括许可他人使用的权利和转让其拥有版权的权利。
复制权, 是指将开源软件制作成一份或多份的权利。根据开源软件许可证, 开源软件可以任意的被他人复制, 即开源软件的开发者允许他人复制其成相应软件, 不受权利人的限制。但是, 对于复制过程中产生的后果及连带责任, 开源软件协议明确了无担保责任的免责条款。
发行权, 是指发布开源软件的权利, 具体是指以出售或者赠与的方式向公众提供软件原件或者复制件的权利。在不改变原软件许可证的前提下, 开源软件使用者可以向任何人提供该软件, 包括赠与及销售。开源软件协议没有限制用户出卖自己获得的开源软件。
出租权, 是指有偿许可他人临时使用程序复制件的权利。开源软件通过许可协议将复制权、再发布权都授予软件的使用者, 所谓出租权已不存在现实意义。因此, 开源软件的出租不受限制。
网络信息传播权, 是指以有线或无线的方式向公众提供软件, 使公众可以在其个人选定的时间和地点获得软件的权利。信息网络传播权在本质上是复制权和发行权的结合, 既然开源软件许可证将这两项权利都授予软件用户, 那么对原始软件的网络传播权也是开放给用户使用, 并无过多的制约。
翻译权, 是指将开源软件所用的自然语言文字转换成其他自然语言的文字的权利。需要说明的是, 将软件的源代码用其他计算机语言重新编写不属翻译权的范畴。只要不是将开源软件再次发布, 公众可以将原软件翻译成其他语言, 这在原则上是允许的, 但是应当注明译者的名字, 以免影响原软件的声誉。
开源软件权利人还拥有许可他人行使专有权及转让著作权的权利。包括开源软件权利人可以许可他人行使其软件著作权的各项权利, 以及权利人可以全面或者部分转让著作权, 并依照约定获得报酬。正是基于该项权利, 开源软件权利人可以通过开源软件许可证对使用人进行约束。这也意味着开源软件权利人对自己经济权利的让渡, 放弃了部分获得报酬的权利。
3.3 作品附加管理信息及措施受保护的权利
随着信息技术的数字化进程加快, 对软件或程序的复制越来越简单, 商业软件一般会采取某些技术措施限制这种未经许可的复制行为, 典型如禁止商业软件的盗版复制或破解使用。我国法律规定, 故意避开或者破坏权利人为保护其包括计算机程序在内的各种数字形式作品而采取的技术措施, 故意删除或者改变作品权利管理信息, 均属于侵权行为。
开源软件用户的修改、复制和再发布软件权利是依据开源软件许可证而接受限制的。作为开源软件本身, 其作品附加管理信息及措施受保护权利是存在的。但是, 如果因为开源软件本身作为技术措施受保护而限制用户修改该软件, 则违背了开源软件精神。因此, 一些开源软件协议明确规定并限制使用开源软件被用作版权技术保护措施。
虽然在本项所述涉及权利方面, 上述假设情况没有十分突出的矛盾。但是, 开源软件许可证只对当事各方 (软件作者和使用者) 产生约束力, 没有对第三方约束的效力。因此, 开源许可证可以在一定程度上阻止开源软件被用作版权保护措施, 但却不能根本性的改变这种做法。这在一定程度上反映出开源软件精神与知识产权保护价值理念的固有冲突。
4 结束语
开源软件是一类遵从开源软件许可证发布的计算机软件, 具有完全开放的源代码特点。开源软件许可证是一种协议, 约束和限制了软件作者和使用者, 也使得开源软件在软件著作权方面具有众多显著的法律特征。通过分析这些法律特征发现, 单纯的著作权法律法规并不能完全涵盖涉及开源软件使用和开发的知识产权相关法律事务调整范围, 还存在一些潜在的过程风险。一些研究学者也提出采用著作权法、专利法和电子信息管理等综合性知识产权保护方法实现对相关开源软件工作的系统性调整。总之, 开源软件在相关法律法规方面还是一个新鲜的事物, 知识产权涉及的方方面面制度尚不健全。后续将围绕开源软件的专利法特征及法律法规适用性等问题进一步开展研究。
参考文献
[1]秦勤, 刘春年.网站构建中开源软件许可分析
[2]林枋.开源软件的许可证浅析[J].科技广场, 2009, (05) :242-243.
[3]张平, 马骁.开源软件对知识产权制度的批判与兼容 (一) [J].科技与法律, 2004, (01) :54-61.
[4]张韬略.开源软件的知识产权问题研究——制度诱因、规则架构及理论反思[D].北京:北京大学, 2004.
[5]秦明.开源软件知识产权保护若干问题研究[D].重庆:西南政法大学, 2006.
[6]车璐.开源软件法律问题研究[D].长沙:湖南大学, 2007.
[7]杨宜坚.开源软件知识产权法律问题研究[D].上海:华东政法大学, 2011.
[8]马龙.开源软件开发和使用之法律问题研究[D].济南:山东大学, 2011.
[9]穆合义.开源软件许可证研究[D].长沙:中南大学, 2009.
[10]闫晔, 李超.基于开源软件开发专有软件的知识产权保护[J].重庆理工大学学报 (社会科学版) , 2013, 27 (07) :22-25.
软件特征 篇2
关键字：物流，软件
第一，标准化：彼得.杜拉克说：“管理就是原则”，也就是说，管理的本质中最为本源的东西就是：标准化、流程化。MySCM中蕴含了诸多世界500强企业成功的现代物流管理与供应链管理最佳实践，并且渗透了中国极具特色的整体创新，如国内独创的物流规则计费引擎、复杂多样的物流业务规则引擎，实现了物流供应链数据处理的全面控制，全面协调整个物流供应链系统的控制和管理能力，大大提高工作的效率和规范性。通过MySCM标准化的应用，企业能快速复制成功管理经验，快速提升管理水平。
第二，一体化：MySCM为客户提供了一体化多层次的集约管理，能统一资源配置、统一物流作业过程、统一整合物流资源、统一规范物流费用，实现数据全局共享、清晰全程透视订单物流过程，通过良好的数据交换接口实现与其他应用系统的高度无缝集成。
第三，精细化：细节决定成败，MySCM是国内唯一具备精细化特点的物流供应链管理软件。MySCM提供了上万种参数设置，如出入库参数、库存参数、计费参数等，让复杂繁乱的物流细节变得清晰明了，事无巨细，细而不乱，对企业物流业务和管理的细节做到最大程度的准确化、精细化。MySCM实现中心公司、供应商、客户和合作伙伴的供应链组织管理，缩短企业管理垂直间隔，实现高度透明的精细化运营管理模式。
第四，量化：企业对业务的掌控程度要求越来越高，需要物流供应链管理软件能提供量化的数据信息，把供应链量化为指标以便考核，使物流供应链管理软件更为准确的为企业提供支持和决策服务。MySCM量化的主要体现就是通过几十种优化算法和大量的数据计算实现业务的准时化作业，从采购、生产、配送、销售全过程的进行量化，通过优化算法算出来的最佳线路、最优储位、最优配送时间、最低成本等，从而实现业务准时化和量化。
第五，智能化：就是自动判别，随着企业要处理的业务越来越复杂，个性化需求越来越多，就要求软件的智能化、自动化水平不断提高。MySCM的智能化主要体现于独特的引擎机制，通过多种订单规则独创订单引擎，指导订单的决策调度，完成复杂的订单处理，对订单进行全生命周期跟踪；通过多种计费规则独创计费引擎，计费引擎自动按订单执行过程计算物流费用。MySCM通过上千张报表，经过数据挖掘，不同经度和纬度的视角为企业提供决策和管理依据。所有这些都是智能化、自动化。
第六，优化：物流系统优化是其降低供应链运营总成本的关键点所在。优化的系统是高效协作的物流供应链系统，提供了最佳的优化策略，提高了协作效率，大大提升了企业的核心竞争力。MySCM提供了四大优化方案和二十多个子优化方案，其中最重要的是优化物流网，从仓储选址决策、库存优化、配送路线优化、配载优化、运力资源优化等全方面进行优化，提供服务质量，功能拓展，继而降低供应链运营总成本。
软件特征 篇3
军用电子装备仿真训练软件 (Military Electronic Equipments Training Simulation Software, 以下简称METS) 是一类在商业货架计算机软硬件平台上运行的, 以装备训练为主要目的的计算机软件[1]。该类软件主要通过对武器装备的人机交互界面、行为逻辑的仿真, 实现人在回路式的操作训练功能, 是当今训练领域提高受训人员掌握窝气装备操作水平的一种重要手段。作为一种典型的军事训练应用系统, 其开发和研制面临着模型重用性不高、开发效率低等问题。这些问题已成为严重影响METS设计与开发周期和质量的瓶颈。
因此, 考虑开发一套能够解决上述问题的METS集成开发环境就显得尤为重要。随着软件工程的不断发展, 领域工程、模型驱动开发等相关技术为软件复用提供了基本的技术支持, 能使特定领域的软件复用活动相对容易的取得成功。虽然在这些技术的理论研究方面已经取得了不少成绩, 但将其应用于软件开发的实例[2,3,4]仍较为有限。而领域分析是能否成功应用领域工程方法实现软件复用的关键。FODA (Feature Oriented Domain Analysis) [5,6]是目前较为成熟的一种面向特征的领域分析方法。该方法支持某领域中各具体应用中共性和个性的发现。因此, 本文研究的重点内容是采用面向特征的领域分析方法建立METS开发领域的特征模型。即以实现METS集成开发环境为目标, 从建立METS开发领域的需求模型入手, 通过提取METS开发领域的共性和变化性特征, 构建出该领域的特征模型, 最后结合领域工程和模型驱动的软件开发方法构建出METS集成开发环境, 以满足各类METS软件的开发需求。
一、特征模型和FODA方法
从实施过程来看, 领域工程包含领域分析、领域设计和领域实现等三个阶段。领域分析是的输出产品是领域模型, 即获取领域需求, 它是针对领域的需求规约模型。特征是从用户角度对系统的感知, 文献[7]提出把特征作为系统需求规约的组织方式。因此, 对系统需求规约提取特征, 并将其进行模块化组织, 是构建领域模型的一种有效手段, 从而形成领域特征模型。
领域特征模型通过记录领域内的特征以及特征之间的关系来反映整个领域的软件需求。这组特征分属于两种类型:共性特征和变化性特征。共性特征存在于领域内的每个具体系统中, 是使领域特征模型能够复用的关键。例如, 在各类METS中, 存在着大量相同行为特征的操作元件 (多波段开关、旋钮、灯、数码管等) , 同时还有行为特征不同的能如显示器元件。变化性特征反映了领域内的不同应用系统中的差异[8]。特征模型通过特征的可选性和变化性来表示领域变化性的机制。其中, 特征的可选性是指部分特征相对于整体特征的可选性, 如视图缩放为仿真对象操作的可选行为特征。此外, 还通过维度 (dimension) 和值 (value) 的概念来描述特征具有的变化性[9]。把具有变化性的特征称为一个维度, 把其涵盖了不同细节的变化性特征称为该维度上的一个值。对于一组同一维度变化特征可采用多选一和多选多两种剪裁方式, 如元件等仿真对象的尺寸设置就是一个维度特征, 这个维度上具有精确设置和概略设置两个值, 同时该维度特征具有多选一特点。与传统软件需求规约的组织结构相比, 特征模型具有可复用性、结构良好、易于图形化建模等诸多优点[10]。
FODA是一种将特征模型引入领域工程中的较为成熟的领域分析方法。随着的领域工程研究的不断深入, 还发展了其它一些以特征模型为核心的领域分析方法 (FORM[11], Featu RSEB[12], PLA[13]) 。运用FODA等领域工程方法, 在开发领域新系统时, 可根据领域模型, 选择确定需求规约, 进而选用合适的系统架构, 并以此为基础选择构件进行组装, 形成新系统。其优点是新系统的开发是建立在对需求、构件等模型复用的基础上。也就是说, FODA正是通过捕捉领域设计阶段的共性和变化性特征, 建立特征和特征之间的关系, 以此来实现以领域特征模型为核心的领域模型。本文的重点将关注于如何建立METS开发领域的特征模型。
二、FODA特征建模过程
领域特征的分析活动的输入是各类领域应用, 输出是领域特征模型。建立特征模型的过程主要包括:服务分析活动、功能分析活动和行为分析活动三个层次, 同时, 每一层次的分析活动内都会伴随着领域术语分析、共性变化性分析、交互过程分析等并发活动, 具体分析活动流程如图1所示。需要特别说明的是, 其建模过程不是一个严格的顺序过程, 各层之间的活动可以出现交替。因此, 实际的建模过程是在这三个层次对应的分析活动之间不断迭代、反复进行的。
服务分析活动的主要内容是识别领域具有服务的特征。其目的就是为每一种典型的业务能力定义领域内统一的名称和说明, 并将其作为特征模型服务层内的特征。如在METS中将模型设计及驱动机制可统一为模型驱动服务。
功能分析活动的主要工作是识别服务具有的功能特征。首先, 分析系统为完成特定的服务必须具有的功能。然后, 为每个功能定义领域内一致的名称和说明, 并将其作为功能层内的特征, 同时建立与服务层特征的整体部分关系。例如, 在各类METS中, 用户需要对多波段开关、数码管等仿真对象进行增、删、改等编辑和位置、尺寸设置等操作, 从而确定出仿真对象管理服务的功能特征。
行为分析活动的主要工作是识别功能具有的行为特点。该层活动主要是为每一种行为特征建立领域内一致的名称和说明, 并将其放入特征模型的行为特征层, 同时建立与功能层特征的整体部分关系。该项活动主要包括分析功能执行的条件特征, 如前置条件、准备工作等;分析功能主体行为的特点, 发现其具有的显著特点和可能的变化性;分析功能的后期行为特点, 如功能执行的后置条件、善后处理工作、功能执行完毕后的控制权转移等。
三、METS特征模型建模
3.1 METS开发领域。
METS集成开发环境主要应用于军用电子装备的行为建模、用户界面可视化编程、软件系统集成等方面。从用户角度来看, 该平台是一种允许用户直接操纵具有特定语义或表示特定物理对象的图形符号进行METS开发的软件系统。例如, 用图像图元或特殊形状的图元表示一个特定的电子元件类型, 用线形图元表示元件之间的接口连接, 用户可以随时操纵这些元件和图元进行建模或设计活动。从功能角度来看, 该平台构成了声纳、雷达、指控等不同专业领域的一个通用军用电子装备仿真训练软件开发领域, 专门负责为用户提供直观、简便的软件开发。虽然在不同的专业领域中, 人机界面上元件表示的语义以及元件之间存在的约束关系有很大的不同, 但是, 在对这些专业领域的变化性进行抽象、隔离和封装的基础上, 我们可以得到一个具有相同行为特征的功能区域, 如元件模版 (多波段开关、数码管等) 。METS集成开发环境具有的直观性、虚拟性、易修改性等特点, 可以极大地提高其在该领域的建模或设计工作的效率。
3.2 METS特征建模
3.2.1 服务层特征模型。
用户通过操纵面板、元件、图元等仿真对象可完成METS的人机交互界面设计, 仿真对象所对应的参数被存储在系统参数库中, 通过仿真模型设计完成用户业务模型的开发, 通过仿真引擎提供的参数模型注册服务完成系统参数与仿真模型的注册信息。在软件发布运行后, 用户操作界面元件, 仿真引擎在采集到此类操作信息后更新系统参数库中对应的参数值, 同时, 仿真引擎以此参数地址为输入在仿真模型注册信息表中找到对应的仿真模型, 并驱动仿真模型的执行, 模型的输出仍通过仿真引擎提交给人机界面进行显示或提交给网络接口进行发送, METS具有各种特征的逻辑结构如图2所示, 从中可以看出, METS是以仿真引擎服务为核心, 将其它服务有机地联系到了一起。从上述METS的开发过程可得出, 其集成开发环境应所具有的服务特征应包括仿真对象管理、模型驱动、运行时管理三部分。限于篇幅, 本文仅介绍前两部分的功能特征模型和行为特征模型, 对于运行时管理的服务特征、功能特征及其行为特征将另撰文描述。
3.2.2 功能层特征模型。
仿真对象管理用于给用户提供面板、元件、图元等仿真对象的编辑及管理操作。其中, 元件对应于实装操作界面的基本物理元素, 除具备可视化图元外, 还具备相应的显示、操作方法;图元是组成元件的基本元素, 同时具备相应的操作方法;面板是元件的管理容器, 用来实现元件对象的创建、初始化以及元件与元件参数的对应关系注册等功能, 同时完成界面布局。从中可以看出, 图元与元件作为用户的设计构件具有可重用性。仿真对象管理服务的功能特征实质上就是面板设计, 其中对象编辑和对象操作是多选特征。
模型驱动服务是METS集成开发环境中最核心的部分, 通过模型设计和参数管理功能能够为METS提供仿真模型的设计、系统参数管理, 以及二者之间的注册信息。通过共性变化性分析, 认为系统仿真模型除了具有属性特征外, 还应包括两种模型:系统回调模型和用户模型。因此, 应给用户提供自定义属性、自定义方法和回调接口编辑功能。其中, 系统回调接口是模型设计的必选功能特征, 自定义属性和方法是模型设计的可选功能特征, 其中参数管理包括参数编辑和参数注册两个必选功能特征。
运行时管理服务通过仿真引擎的驱动功能来实现METS运行时的模型调度。
METS集成开发环境的功能层特征模型如图3所示。
3.2.3 行为层特征模型。
在服务分析和功能分析的基础上, 可对每个系统功能的行为特点进行分析。通过考察用户对面板、元件、图元等仿真对象的编辑操作可以发现, 仿真对象编辑功能层的行为特征应包括:元件/图元对象的增加、删除、修改。通过考察用户对面板、元件、图元等仿真对象的典型操作可以发现, 仿真对象操作功能的必选行为特征应包括:元件/图元的组合、选择、撤销/重复、图层设置、设置位置、设置尺寸等。由于显示设备物理尺寸的限制或对局部细节的要求, 用户可能需要缩小或放大视图以便能够观察到视图的整体布局或局部细节, 因此视图缩放应作为可选行为特征。其中, 对象选择维度上有单选和多选两个值, 位置设置特征维度上有精确设置和概略设置两个值, 并且对象选择和位置设置的行为特征为多选一模式。
系统回调接口是指METS仿真引擎提供给用户的通用系统回调接口, 如面板初始化、状态变化相应等, 在系统回调接口中用户可处理这些系统响应。从模型的表示形式上看, 系统回调接口与用户的仿真模型都具有一些共性特征, 即都由模块编号、输入参数、输出参数、计算单元四部分组成。但系统回调接口的模块编号、输入参数、输出参数为系统定义, 用户只需处理计算单元。因此, 在METS集成开发环境中, 系统回调接口功能层的必选行为特征为回调接口编辑。自定义方法的行为必选特征包括:设置输入参数、设置输出参数、设置方法名称。系统提供默认的返回类型, 同时允许用户根据自身需求进行修改, 即设置返回类型为可选行为特征。自定义属性的必选行为特征为设置属性名称, 可选行为特征为设置属性类型, 设置属性类型纬度有整形、字符串等值, 且为多选一模式。
对于METS中的系统参数来说, 每个参数具有唯一标识, 用户除了能对参数进行基本编辑操作外, 更重要的是能够将参数与面板、元件、图元、仿真模型进行关联注册, 此操作是实现模型驱动的核心操作。通过交互过程分析, 可发现系统参数编辑功能的行为必选特征包括:增加、删除、设置名称、设置初始值, 设置类型、修改唯一标识号为其行为可选特征。系统参数注册功能的行为必选特征包括:参数选择、注册类型选择、模型IO参数选择, 其中选择注册类型维度上有两个值, 且为多选一模式, 表示既可通过鼠标拖动实现, 又可通过向导创建。
通过上述分析, 可得到图3所示的METS集成开发环境的行为特征模型。具体符号语义参见文献[9]。
四、结论
软件特征 篇4
关键词：android,信息安全,恶意代码,代码分析
Android是一种基于Linux的自由及开放源代码的操作系统, 主要使用于移动设备, 如智能手机和平板电脑, 由Google公司和开放手机联盟领导及开发。2012年11月数据显示, Android占据全球智能手机操作系统市场76%的份额, 中国市场占有率为90%。
Android会同一系列核心应用程序包一起发布, 该应用程序包包括客户端, SMS短消息程序, 日历, 地图, 浏览器, 联系人管理程序等。所有的应用程序都是使用JAVA语言编写的。手机中存储了个人的日常生活隐私和通信隐私等等, 因此android下的恶意软件危害及其严重。黑客可以通过android恶意软件、木马程序等攻击用户, 用户一旦遭受攻击, 将会暴露大量的隐私信息, 会带来诈骗、钓鱼、重要文件失窃等事件, 更有可能带来不可估量的经济损失。
1 Android软件APK结构和功能分析
Android应用程序包文件 (APK) 是一种Android操作系统上的应用程序安装文件格式, 其英文全称为“applicationpackagefile”。任意一个Android应用程序的代码想要在Android设备上运行, 必须先进行编译, 然后被打包成为一个被Android系统所能识别的文件才可以被运行, 这种能被Android系统识别并运行的文件格式称之为“APK”。
APK文件是基于ZIP文件格式, 它与JAR文件的构造方式相似。它的互联网媒体类型是application/vnd.android.package-archive.通过观察Android工程在Eclipse的目录结构分布。
2 基于代码特征的恶意代码特征库构建原理和设计
首先采集样本, 样本来源于contagiominidump.blogspot.com。人工构建敏感API名单, 通过对SDKAPI的分析, 将获取联系人、短信、通话、网络、录音、GPS、摄像等相关的API作为初始化敏感API。
Zip APk批量解压模块, 利用zlib库实现, 通过代码实现全自动解压缩, 将获取的样本逐一解压。APK缓存文件生成之后交由Dex2Jar处理。
Dex2Jar依赖于JDK环境, 将.dex/.odex的二进制字节码反编译, 转换为java的Jar包。
JAR (Java Archive, Java归档文件) 是与平台无关的文件格式, 它允许将许多文件组合成一个压缩文件。通过zlib库将得到的Jar文件进行解压缩处理, 放入缓存, 已备后续流程处理。
Jar预处理完成交由Smali->java模块处理, 该模块由Jad实现, Jad将生成smali文件反编译为能够有文本编辑器识别的Java代码, 将所有当前生成的Java文件夹放入缓存, 交由文本匹配模块进行特征提取。
根据手工设定的敏感API进行特征提取, 将每个样本的敏感API组合特征和出现频率等进行统计和入库。
3 基于代码特征的恶意APK静态分析系统原理与设计
恶意代码样本库特征初始化完成, 有本部分完成对待分析APK的恶意代码的静态分析。
首先将要分析的APK输入到该系统, 通过Dex2Jar, Jar转换Java代码文件, 待分析代码放入缓存区域, 将待分析代码输入到特征匹配模块, 利用之前生成的恶意代码特征库进行特征匹配, 将匹配的结果生成到分析报告中。
4 结语
首先对Android系统进行了简单的介绍, 并简略的叙述了当前Android恶意软件带来危害, 然后通过对Eclipse工程项目的结构对APK结构进行了简要的分析, 并分别介绍了各自的功能, 恶意代码通常包含在dex文件之中, 不排除有部分恶意软件动态加载加密的资源执行隐藏的代码。
在最后提出了Android下APK中的恶意代码特征库组建模型, 叙述了它的实现流程和原理, 再次基础上设计基于代码特征的APK恶意代码分析系统, 通过对特征的提取和分析得出分析报告。
该设计是在特征库足够完备和权重指标足够完美的前提下运作的, 能够更加快速的分析软件恶意特征。
参考文献
[1]戴明星, 陈正奎.Web网站的安全代码设计[J].信息安全与通信保密, 2010.
[2]wxSQLite3.wxSQLite3 Source Code[EB/OL]. (2011-02-12) [2012-09-15].
[3]刘嘉勇, 方勇, 胡勇.应用密码学[M].北京:清华大学出版社, 2008.
[4]李鑫, 周安民.对多种Web语言嵌套的跨站过滤分析[J].信息安全与通信保密, 2012.
[5]徐少培, 姚崎.基于操作劫持模式的Web攻击与防御技术研究[J].信息安全与通信保密, 2011.
软件特征 篇5
辽宁某港区建设前导工程中, 我单位承担海浪观测任务, 海浪观测设备选用某厂家提供的遥测波浪仪, 配备一套岸站接收系统, 通过GSM网络以点对点短信方式进行数据传输。
遥测波浪仪按技术要求布放后, 岸站数据接收系统在实际运行中数据接收成功率不足30%, 分析其主要原因是遥测波浪仪布放位置的GSM网络信号较差, 数据完成采集后经常由于网络连接不畅无法发送数据。鉴于此, 只能通过定期拷贝遥测波浪仪原始数据文件, 然后人工逐文件在原始数据文件中计算、提取波浪特征值。由于遥测波浪仪每小时采集一次并生成该时次原始数据文件, 每个原始数据文件中又包括12个波浪数据参数, 累积每月需处理约720个文件、8640个数据, 由此给工作人员带来了繁重的额外工作。不仅如此, 由于原始数据文件数量大, 人工方式效率低、准确度差, 为保证按进度完成观测数据分析处理任务, 工作人员经常加班加点, 压力较大。
Visual Basic for Applications (VBA) 是Visua Basic的一种宏语言, 主要能用来扩展Windows的应用程式功能, 也可说是一种应用程式视觉化的Basic Script。通过VBA, 可以实现复杂逻辑的统计 (比如从多个表中, 自动生成按合同号来跟踪生产量、入库量、销售量、库存量的统计清单) 等。在国内, 利用VBA进行业务自动化处理已经得到广泛应用。本文拟通过VBA平台开发一款软件, 实现自动提取波浪特征值, 改变人工逐文件提取波浪特征值的现状, 从而提高工作效率。
2 软件的开发与实现
2.1 流程图
根据波浪特征值的定义及现有海洋观测系统的数据处理格式要求, 讨论确定原始数据转化为特征值的编程算法及流程图。整个过程中, 需要处理的参数有采集日期、采集时次、波级、综合波向、最大波高及周期、1/10大波波高及周期、有效波高及周期、平均波高及周期和波数等12个。
软件处理流程图如图1。
2.2 关键算法代码 (图2)
2.3 软件实现
波浪特征值提取软件, 提取每个原始数据文件中的日期、采集时次、平均波高及对应周期、最大波高及周期、1/10大波波高及对应周期、有效波高及对应周期、波数、波向等12个参数, 然后将它们保存到新的文件中, 处理过程如图3。
3 软件测试
3.1 测试过程
遥测波浪仪每小时采集一次并生成该时次原始数据文件, 每个文件中包括12个波浪数据参数, 累积每月需处理约720个文件、8640个数据。我们取6月份整月数据进行测试, 据上述, 该月有720个文件、共8640个数据需要处理。
测试分两个方面进行, 一是工作效率, 分别计算软件和人工处理该月数据所用时间, 然后进行比较;二是准确率, 将软件和人工提取的该月波浪特征值分别与原始数据进行比较, 计算其准确率, 然后进行比较。
测试工作于2013年7月份进行, 测试进度安排见表1。
3.2 测试结果
3.2.1 工作效率
对人工和软件提取波浪特征值用时分别进行统计, 结果如表2。
由表2可见, 人工与软件提取波浪特征值用时相差悬殊, 其比例比达到60:1。由此可见, 利用该软件提取波浪特征值的工作效率远高于人工操作, 是人工工作效率的60倍。
3.2.2 准确率
在测试过程中发现人工提取特征值有出错的现象 (见图2) , 而软件自动计算获得特征值未发现错误。人工和软件提取波浪特征值的准确率比对情况见表3。
通过表3比对可见, 人工提取的8640个波浪特征值参数中, 累计错误数据总量为42个, 准确率为99.5%。其中, 除采集日期和采集时次外, 其余10个参数均有错误出现, 单项错误数据最高15个, 出现在波向值, 准确率只有97.9%。软件提取数据8640个, 无错误数据发现, 准确率达到100%。
鉴于人工提取波向数据准确率最低, 分析发现, 波向数据在提取时, 观测员需要先对16个原始波向值按要求进行排序, 然后选取最大值作为综合波向, 若最大值为两个相同值, 取前一个值作为综合波向。在排序和选取最大值过程中, 人眼长时间面对单调数据, 易发生疲劳, 此时准确率不能得到充分保证。采用软件计算后, 程序按照预先设定的规则自动对数据排序并计算最大值, 准确率大大提高。
4 结束语
该软件7月份完成测试后即投入使用, 目前已完成5个月份3672个数据文件处理工作, 提取波浪特征值数据44064个, 经抽样检查, 无错误发现, 运行良好。
通过前期测试和5个月的运行, 我们看到软件已经实现设计目标:不仅显著提高了工作效率, 把人工60小时的工作量压缩到1小时完成;而且将准确率达到一个新的高度, 从97.9%达到了100%, 充分保证了数据质量, 为后续使用打下了坚实的基础。
最后, 希望以本文为启发, 进一步拓宽海洋观测监测数据自动化处理的应用范围。
摘要：利用遥测波浪仪进行波浪观测时, 如果其布放点周围无线通信网络信号较差, 岸站数据接收成功率较低, 此时获取波浪观测数据-波浪特征值的唯一方式是人工方式逐文件进行提取。本文开发的软件通过VBA平台, 实现了从遥测波浪仪的原始数据文件中批量自动计算并提取波浪特征值, 从而改变了人工逐文件计算、提取波浪特征值的现状。该软件不仅极大提高了工作效率, 而且准确率达到100%。
关键词：VBA,提取,波浪特征值
参考文献
[1]冯士筰, 李凤岐, 李少菁.海洋科学导论[M].北京:高等教育出版社, 1999年6月.
[2]Rob Bovey.Excel 2007 VBA Programmer’s Reference[M].New Jersey:JOHN WILEY&Sons, Inc., Mar 2007.
[3]Rod Gill.VBA Programming for Microsoft Project'98 Through[M].Perfect Paperback.Mar 2011.
[4]沃肯巴赫.中文版Excel2010高级VBA编程宝典[M].冉豪, 崔婕, 金太阳译.北京:清华大学出版社, 2012年12月.
软件特征 篇6
软件产品线是共享一组受控的公共特征,满足特定市场需求,并且在一组预定义的公共核心资产基础上开发而成的一系列软件系统[1]。
自从特征的概念被引入到产品线开发过程之后,基于特征的领域分析技术就成为主流并且得到了广泛应用。特征模型[2]是基于特征的领域模型的一种表现形式,它采用图形化的方式表达领域的需求,定义特征及其关系。
然而,在现有特征模型基础上,如何指导系统开发人员进行软件系统的详细设计是亟待解决的问题。该问题体现在如下方面:
首先,特征之间的层次或依赖关系如何映射为设计模型中元素之间的交互及关联。由于特征模型一般体现为具有层次关系的树状结构,同一层次的结点之间可能具有执行顺序或互斥等语义描述,因此特征模型所对应的系统设计模型中应当保留这些结构与语义信息。
其次,特征的可变性如何映射为设计模型中的可变性实现方案。由于特征模型是应用系统开发定制的基础,特征可变性的绑定需要同步地修改设计模型所体现的系统行为与功能,因此与特征模型相对应的系统设计模型需要显式地体现可变性特征,并且提供便捷的可变性定制方式。
针对以上问题,本文提出一种基于特征分解模式的软件产品线参考设计方法。该方法为特征模型中具有不同结构、不同语义的特征分解模式提供参考的详细设计方案。本方法采用面向对象以及面向方面的设计技术支持特征关系语义的保存以及特征可变性的绑定。本文还提出了相关的聚类准则以支持应对全局特征模型的类层次详细设计模型的优化。
1 基本概念
1.1 特征分解模式
在面向特征的领域分析(FODA)方法中,特征是指软件系统中用户可见的,显著的或具有特色的方面,品质或特性[2]。特征模型是领域工程中描述产品线共性和可变性特征,特征与特征之间关系的需求模型。特征模型一般由树形结构图表示,图中有且仅有一个根节点,根节点通常表示一个系统。特征则由树形结构中的一般节点表示,通过特征名称来识别。
特征分解模式是指一个特征能够可以分解成多个子特征或多层次特征的组合。本文的特征分解模式主要依据传统特征模型的可变性类型来划分的,特征模型可变性类型有四种:必选(mandatory)、可选(optional)、多选一(alternative)和多选多(or)四种。特征分解模式可分为五种原子分解模式和一些复合的分解模式。下文将详细介绍这五种原子分解模式和复合的分解模式。
1.2 特征实现技术
目前主流的特征实现技术是面向对象技术(OOP),其中包括继承、重载、参数化、反射、设计模式等实现技术。对父类的抽象封装,衍生出不同的子类实现可变性,继承可以将主程序中可变性部分抽取出来;对同一方法,重载则可以随参数类型的变化而变化操作;参数化则可以实现大部分可变性类型,但参数化容易使程序中参数的数量过多导致程序可读性和可维护性差;反射的作用是将可变点的绑定改为运行时动态绑定;设计模式则可以在类似情况下重用程序中的设计[3]。这些OOP技术作为产品线实现技术有着各自的优点,但特征实现中可变性部分要求可变点中变体的实现对基础程序的修改尽量少,OOP很难实现这个要求,面向方面编程(AOP)正好弥补了这方面的缺陷,因此我们将使用OOP结合AOP技术作为本文的特征实现技术。
2 特征分解模式及参考设计和实现
2.1 原子特征分解模式
本节详细描述上文中提出的特征分解模式,并对这些特征分解模式提出一些参考的设计和实现。为了使得映射方案简单且易于理解,我们首先基于以下假设:特征与类中的方法一一对应。
2.1.1 普通的必选特征分解
普通的必选特征分解是必选特征的一种,指父特征分解为若干个子特征,子特征之间是独立并列的关系,没有顺序先后和流程控制关系。如图1所示,特征B和特征C是父特征A的必选子特征。从该分解模式的语义定义中可知,父特征的实现是由子特征的方法来实现,所以其实现可以采用普通的方法调用完成,父特征A对应类ClaasA的a()方法,子特征B和C分别对应ClassB和ClassC的b()和c()方法。
2.1.2 带有流程控制的必选特征分解
带有流程控制的必选特征分解是指父特征分解为若干个子特征,子特征之间有顺序先后关系或流程控制关系。该分解模式语义与普通必选特征分解类似,可以采用按流程顺序调用方法或者嵌套方法调用等方式实现。如图2所示,特征B和特征C是特征A的必选子特征,子特征B和C之间的流程顺序是先B后C。父特征A对应类ClassA中的a()方法,必选特征B对应类ClassB中的b()方法,必选特征C对应类ClassC中的c()方法,若b()方法和c()方法之间没有交互,a()方法可以按照流程顺序调用b(),c()方法;若b()方法需要c()方法的运行结果或其他交互时,可在调用b()时嵌套调用c()。
2.1.3 可选特征分解
可选特征分解是指父特征分解一个可选子特征,在应用产品定制时可以选择绑定或者不绑定这个子特征。由于AOP可以在不修改产品线公共资产的前提下实现可变点,使得可选特征具有良好的可移植性,因此可选特征分解的参考实现可以通过AOP技术来完成。如图3所示,Aspect包括切点Pointcut和通知Advice,Pointcut就是基础程序中特定一条语句处设置的一个断点,Advice是指在这个断点前后想要加入的程序代码。特征A对应ClassA的a()方法,特征D对应ClassD的d()方法。当D被绑定时,将可选特征D所对应的方法的d()通过Advice编织到父特征对应的已有方法a()之前或之后即切点的位置,一旦可选特征被选定,则实现编织操作,否则不进行该编织操作。
2.1.4 多选一特征分解
多选一是指父特征分解为多个子特征,在应用产品定制时必须要在这些子特征中选择一个进行绑定。由于多选一特征中的子特征往往具有与父特征相关的共性,多选一特征分解可以使用面向对象中的类继承和反射机制来实现,并利用配置文件来记录产品线定制阶段子特征的选择结果。如图4所示,父特征D映射为基类D中的方法d(),子特征所对应的方法则分别为子类中的(D1.d(),D2.d()),程序通过工厂类获得实际的类对象,利用Java反射机制判断输入类型并返回对应的子类对象,调用相应子类中的方法。
2.1.5 多选多特征分解
多选多特征分解是指父特征分解为多个子特征,在应用产品定制时可以在一组特征中绑定零个或者多个特征。多选多特征分解中,子特征的特性与多选一特征分解类似,应用产品定制阶段决定哪些子特征被包含在系统中,具体哪一个变体被选中则在运行时决定,所以在用类继承机制的同时,还需要添加一段用来支持用户选择的代码或UI (User Interface),具体的子特征选中则由用户选择或其他程序完成。如图5所示,父特征E映射为基类E中的方法e(),子特征所对应的方法则分别为继承该基类的子类中的(E1.e(),E2.e()),不同的是多选多实例化的子类可以为多个,具体的变体则在获取用户决策之后决定。
2.2 复合特征分解模式
复合分解模式由多种原子特征分解组成。必选特征分解、多选一以及多选多特征分解之间的两两组合,过于简单,不需要详细讨论。但是,与原子分解模式相比,可选特征分解和其他几种分解组合具有一定的特殊性。可选特征分解和其他几种分解组合模式包括可选加普通必选特征分解,可选加带有流程控制的特征分解,可选加多选一特征分解,可选加多选多特征分解。这四种复合模式的特征分解其实现并不能由两种原子分解模式简单的组合从而得以实现,因为在某些实现中中间层的可选子特征有时仅仅用于过渡,在实现中没有与之对应的具体类方法。因此,当使用aspect时切入点就有可能有多个,advice编织的方法也各不相同,这就需要使用多次aspect。而可变性的绑定方式也可能是不同的,例如可选加多选多的特征分解模式,可选特征分解是定制时绑定的,而多选多特征分解则是运行时绑定的。
2.3 全局类设计
本文研究是基于一个特征追踪到一个类方法的假设下进行的。通过本文特征分解模式得到的类层次设计中一个类只有方法,显然是不合适的,因此为了使通过特征模式得到的类图更加合理,我们采用聚类方法,将一些具有特定关联的类以及其的方法合并成一个类。本文使用的一些聚类准则:
(1) 对同一业务对象进行操作且在同一父特征分解下的子特征所对应的类方法放入一个聚集。
(2) 在同一父特征分解下的子特征所对应的类方法且方法与方法之间存在直接调用关系的类放入一个聚集。
(3) 如果父特征只是一个过渡特征即没有实际具体功能时,该父特征与子特征所对应的类方法放入一个聚集。
3 案例研究与讨论
3.1 动机案例
成绩录入产品线是教育类单位将各种类型的考试成绩录入到数据库中的软件产品线,该产品线的基本功能包括用户管理、考试信息管理、成绩管理和信息统计等功能。图6所示的特征模型是对成绩录入系统共性和可变性需求的模型图。由于考试类型的重要程度不同以及录入员的计费方式不同,不同单位在成绩录入方式和设置验证码方式,录入员统计方式等方面存在差异。该系统产品线的特征模型如图6所示,包含四个公共大特征“用户管理”、“考试信息管理”、“成绩管理”和“信息统计”等特征。而“用户管理”特征中的“添加监管员”,“考试信息管理”特征中的“设置验证码”,“成绩管理”特征中的“成绩录入”和“信息统计”特征中的“录入员统计”是系统的可变特征。该产品线的开发语言是Java和AOP语言AspectJ。
3.2 成绩录入系统特征分解及参考设计和实现
3.2.1 全局类设计
对成绩录入系统产品线使用2节中特征分解模式的参考设计与实现方法进行类设计,并用2.3节中的聚类准则,得到一个整体的类图,如图7所示。
3.2.2 添加监管员
由于不同考试类型的重要程度不同,对于重要性不高的一般性考试的成绩录入,不需要监管员,“添加监管员”是属于可选特征分解。如图8所示,系统默认情况下不绑定“添加监管员”特征。如果要绑定该特征,需要根据2节中可选特征分解的参考设计给出的方法用Aspect来实现。当可选子特征“添加监管员”被绑定时,将类Supervisor的addUser方法编织到类UserMangement的addUser方法前,其pointcut和advice如图9所示。图9第三行代码表示仅仅把这个Aspect横切到addUser()的调用上,第四行代码表示其横切方式为before,因此在执行addUser()方法之前先执行这个aspect,先用反射验证该方法的参数是否为监管员类型,如果是则执行图8所示的编织过程,如果不是则跳过。
3.2.3 考试信息管理
“考试信息管理”特征与其三个子特征“添加考试种类”,“添加考试科目”,“导入考号信息”的特征分解模式是带有流程控制的必选特征分解。“考试信息管理”的流程是:首先“添加考试种类”;其次,在某一考试类型中“添加考试科目”;最后,对考试科目“导入考号信息”。根据2节中带有流程控制的必选特征分解的参考设计给出的方法,采用嵌套调用来实现。如图10所示,考试信息管理类ExamInfoManage初始化函数infoInit()调用了添加考试种类函数ExamFactory.addExam(),添加考试科目SubjectFactory.addSubject(),而添加考试科目嵌套调用导入考号信息Subject.ImportStuInfo()。
3.2.4 设置验证码
“考试信息管理”特征下的“设置验证码”特征及其子特征“手动设置”“批量设置”隶属于可选加多选一的复合分解模式,“手动设置”和“批量设置”是两个多选一变体特征,实现“手动设置”和“批量设置”的类分别是DigitalCode和FileCode类,它们都被定义为Input类的子类。如图11所示,通过验证码工厂类VerifyCodeFactory的getVrifyCode()方法获得实际的验证码类对象,该方法再利用Java反射机制判断参数类型并返回相应的验证码类对象。当可选特征“添加验证码”被绑定时,编织如图12所示的Aspect,该Aspect的pointcut和advice的实现方式与图9“添加监管员”的Aspect类似,这里就不赘述。
3.2.5 录入员统计
“信息统计”特征下的“录入员统计”特征与其两个子特征“录入量统计”“错误率统计”是可选加多选多的复合特征分解。该分解模式与3.2.4中“设置验证码”的分解模式的实现相似,只是多选多变体特征的绑定是运行时由用户选择的,这里就不赘述。
3.3 讨 论
在方法验证上,本文首先建立了成绩录入软件产品线创建特征模型,并根据3.1节中提出的特征分解模式,分析了该案例中所包含的特征分解模式。为了实现特征分解模式到产品线设计实现的映射,案例中的实现以第2节中提出的特征分解模式参考实现方法为依据,综合使用很多传统面向对象编程中的继承、重载、参数化、反射以及设计模式等实现技术。本文还使用AOP技术的特殊机制,在不修改产品线公共部分程序的基础上实现可变点,使得产品线可变部分具有良好的可移植性。综上可以看出,本文方法对处理特征分解模式到软件产品线设计实现的映射是非常有效的。
4 相关工作
产品线特征模型及基于特征模型的设计和实现技术是软件产品线领域的研究热点。文献[3]提出结合OOP和AOP两种实现技术实现产品线系统。文献[4]对 AOP作为产品线实现技术的可行性进行评估,并通过案例进行分析与论证。文献[5]提出将特征分析和AOP结合可提高产品线的复用性,可移植性和可配置性。文献[6]引入本体作为特征模型的描述基础,提出了一种基于特征模型和构件语义的概念体系结构设计方法。文献[7]基于特征模型上研究了产品线的增量泛化,并用JBoss-AOP作为可变性实现技术。这些研究成果为基于特征模型的软件设计方法给了很好的指导,但还不够成熟:它们都没有结合产品线特征模型,没有涵盖本文所列出的特征分解模式,没有针对特征分解模式提出专用的设计方案。
5 结 语
软件产品线中,系统的详细设计模型应当与特征模型对应,要求保留特征模型中特征之间的依赖与结构关系,同时显式化支持可变性的绑定。本文针对以上思考,提出基于特征分解模式的软件产品线参考设计方法。该方法从简单追踪假设出发,为不同的特征分解模式提供参考的设计方案。同时,以聚类准则为指导,优化全局的系统设计模型。
还应指出,本文的研究基于简化的传统特征模型,并未考虑特征与特征实现之间的多对多映射关系以及特征之间存在依赖、排斥等复杂的交互情况,因此我们下一步的工作将着重考虑对这些问题的解决方法。
摘要：基于特征的领域分析与建模技术是软件产品线开发中较为主流的需求建模方法,为描述产品线共性和可变性及其之间的关系提供了良好的支持。然而在现有特征模型基础上,如何指导系统开发人员进行软件系统的详细设计是亟待解决的问题。该问题主要体现在特征之间的结构与语义关系,以及特征的可变性如何映射为合理的系统设计模型这两个方面。针对上述问题,提出一种基于特征分解模式的软件产品线参考设计方法。该方法为特征模型中具有不同结构、不同语义的特征分解模式提供参考的详细设计方案,并提出相关聚类准则以支持对应全局特征模型的设计模型优化。最后,通过成绩录入软件产品线对该方法的有效性进行验证。
关键词：软件产品线,特征模型,特征分解模式,可变性,共性,实现
参考文献
[1]Paul Clements,Linda Northrop.软件产品线实践与模式[M].张莉,王雷,译.北京:清华大学出版社.2004
[2]Kang K C,Cohen S G,Hess J A,et al.Feature-oriented domain analysis(FODA)feasibility study[R].Carnegie Mellon Univ,Tech Rep:CMU/SEI-90-TR-21,1990.
[3]祝家意,彭鑫,赵文耘.基于OOP和AOP的软件产品线实现技术研究[J].计算机科学,2009,34(7):120-123.
[4]Anastasopoulos M,Muthig D.An Evaluation of Aspect-Oriented Pro-gramming as a Product Line Implementation Technology[C]//ICSR,Spain,2004.
[5]Lee K,Kang K C,Kim M,et al.Combining Feature-Oriented Analysis and Aspect-Oriented Programming for Product Line Asset Development[C]//SPLC,Maryland,2006.
[6]彭鑫,赵文耘,刘奕明.基于特征模型和构件语义的概念体系结构设计[J].软件学报,2006,17(6):1307-1317.
软件特征 篇7
1 计算机软件技术及发展特征
计算机软件技术,是指为了确保计算机的正常运行,而设置的程序或者相关数据,软件是用户与硬件之间的接口界面,是维持计算机正常运转的核心所在,也是用户与计算机进行相互交流的渠道,其能够提升计算机整体结构的全面性、细致性和可靠性。软件技术属于计算机技术的一种,包括数据处理、人工智能、过程控制和科学计算四种类型,基本上计算机的所有功能都是在相关软件的支持下实现的。在信息化技术飞速发展的影响下,计算机软件技术也在持续发展,对于软件技术人员提出许多新的要求[1]。
从目前的实际情况分析,计算机软件技术的发展特征主要体现在几个方面:
1.1 硬件技术发展影响
计算机软件的发展受其他因素的影响巨大,其中比较重要的是硬件技术,先进的软件技术需要可靠的硬件设备作支撑,如果硬件不足,再好的软件也无法有效发挥作用。不过,软件技术的发展也在一定程度上推动了计算机硬件系统的进步,使得其自身拥有了更加广阔的发展空间。伴随着计算机的日益普及,其开始从最初的科研领域深入到了人们生活的各个方面,硬件技术的发展带动了软件技术的进步,反之亦然。
1.2 开发成本持续提高
科学技术的发展和进步,为计算机软件开发工作提供了巨大的便利,但是同时也使得软件开发的成本不断增加,软件成本在计算机系统总成本中占据着越来越大的比重,尤其是一些在专业领域中使用的软件系统,其开发成本更是极其巨大,如军用系统、科研系统等,单单软件的投入费用就可能超过整个计算机系统投入的80%[2]。
1.3 开发难度不断加大
软件本身虽然看似简单,但是其所蕴含的内容是异常丰富的,属于系统全面且具有较强逻辑性的元素。对于计算机软件的开发而言,需要有专业的开发平台,不同类型、不同功能的软件在开发环节所涉及的公式、程序等存在着极大的差异。同时,计算机软件的研发过程具有较强的变化性和随机性,导致其往往难以完全按照与客户的约定完成,还需要继续进行调整和修改,因此开发难度较大。
1.4 内部结构越发复杂
计算机技术整体水平的提升,对于软件也提出了更高的要求,无论是软件本身的规模还是软件技术的复杂程度,都在不断提高,或者可以这样认为,计算机系统成本之所以会不断增加,与计算机软件本身越发复杂的内部结构存在直接的联系。相比较最初的计算机软件,当前多数计算机系统的运行代码扩大了300倍,而且计算机系统的规模也至少增加了三个数量级[3]。
1.5 后期更新维护困难
计算机运行需求及所处环境的不断变化,对于软件系统也造成了巨大的冲击,无论多么优秀的计算机软件,在长期的使用过程中,都不可避免地会出现各种各样的漏洞和问题,在这种情况下,想要保证用户的良好体验,确保软件的正常使用,就必须做好后期的更新和维护工作。而软件系统的维护是一个异常庞大的工程,也许在费尽心力解决当前的问题后,又会随之出现新的问题。不仅如此,想要做好计算机软件的更新维护,维护人员必须对软件本身的开发过程有一个大致的了解,提出相应的解决办法,否则就可能会陷入僵局。
2 计算机软件技术的不可靠性
计算机软件的可靠性是确保其功能有效发挥的关键所在,其不仅关系着计算机的正常运行,关系着用户体验,更在很大程度上关系着用户的数据信息安全,因此受到了越来越多的关注。而从本质层面分析,计算机软件的可靠性主要是针对计算机软件性能及质量的研究,结合相应的规范和标准,进行软件的全面评估。或者简单来讲,计算机软件的可靠性,就是针对计算机软件故障和问题的研究,在综合考虑各种因素影响的情况下,合理评估计算机软件出现故障的可能性,确定故障发生的概率,将其作为评估计算机软件可靠性的重要指标。通常来讲,在一款软件研发完成投入市场前,都需要进行相应的检验工作,以确保其能够可靠运行[4]。但是从目前来看,我国在计算机软件的可靠性研究方面存在着一些不足,也因此导致了计算机软件技术的不可靠性,具体来讲,主要体现在两个个方面:
2.1 内部因素
导致计算机软件技术不可靠性的主要原因,是设计环节存在的缺陷和漏洞。就目前而言,在进行计算机软件的开发设计时,主要是立足客户需求,搭建大致的软件框架,对研发方向进行明确,然后通过人工的方式,进行代码以及相关程序的编写,不仅十分繁琐,而且软件编程的质量和最终效果直接受设计人员专业素质的影响。如果软件编程人员本身具有较高的专业素质,对工作认真负责,则最终得到的软件就能够满足客户的各种需求,软件的性能和质量也就有所保障。反之,如果编程人员在进行软件开发的过程中,出现了错误,则不仅会影响软件的性能,甚至可能会给整个计算机系统带来巨大的安全隐患。不仅如此,软件编程需要写入大量的代码,而这些代码只能由人工完成,在实际操作中受各种因素的影响,误差的存在几乎不可避免,这就在很大程度上增加了计算机软件的不可靠性。相比较发达国家而言,我国的软件工程发展时间较短,缺乏高素质的专业技术人才,而且相对滞后的计算机运行环境也直接制约了软件的运行效果,其同样会在一定程度上加大软件技术的不可靠性[5]。
2.2 外部因素
就目前而言,我国软件技术正处于飞速发展阶段,但是对于计算机软件技术的开发更多地侧重于技术层面,以实际应用效果来对计算机软件技术进行评估,没有认识到软件技术的不可靠性,从而在一定程度上加剧了不可靠性的发展,甚至可能会形成安全隐患,威胁计算机的正常运行。简单来讲,就是在计算机软件技术的发展过程中,偏重软件的开发而忽视了安全管理,在进行计算机软件的研发工作时,没有设置相应的监督管理体系,不能及时发现和解决软件开发过程中存在的各种问题和不足,在软件开发完成后,也没有及时进行权威性的评估分析,往往是在软件投入市场,出现问题之后,采取进行更新和补救,不仅效率低下,效果欠佳,而且容易失去客户市场。
不仅如此,错综复杂的网络环境同样会对软件技术的可靠性造成负面影响。伴随着网络技术的发展,计算机软件技术想要发挥更好的作用,就必须顺应发展潮流,开展适应性变革,与网络技术相互融合,相互推动。但是与此同时,在网络环境下,计算机软件技术原本的缺陷和问题将会被无限放大,当其没有能够被及时解决,逐渐形成安全威胁时,在网络的传播下,所带来的危害难以估量的[6]。
3 提升计算机软件技术可靠性的有效策略
3.1 关注软件故障
计算机软件技术的不可靠性归根到底就是软件故障的存在,因此,想要提升计算机软件的可靠性,就必须采取切实有效的措施,降低软件故障发生的几率。一方面,在进行软件开发的过程中,设计人员必须加强与客户的沟通和交流,了解客户的真实需求,并以此为导向进行软件的研发设计;另一方面,在软件开发环节,设计人员必须对自身的工作有一个清醒的认识,做到认真负责,避免语句错误、变量错误等一些低级问题。
3.2 强化软件设计
做好软件的设计工作是提升计算机软件技术可靠性的关键所在,也是首要环节。具体来讲,应该加强对于专业软件技术人才的教育和培训,拓展人才队伍,从整体上提升我国计算机软件设计的水平和质量。对于软件编程人员而言,在开展软件研发的过程中,必须做好相应的规划设计工作,结合软件的实际应用需求,编制相应的设计方案,做好可行性分析,在确保软件能够正常运行后,才能着手进行下一步的工作。另外,在软件投入市场前,必须进行专业的试验检测,及时对其中存在的缺陷和漏洞进行弥补,提升软件的可靠性,避免由于人为误操作引发的安全隐患[7]。
3.3 注重监督审查
相关调查显示,在计算机软件的开发和使用过程中,之所以经常出现各种各样的问题,主要是由开发技术人员对于工作缺乏足够认真负责的态度,没有做好硬件系统的维护以及各个阶段的审查工作。对此,为了确保计算机软件在不同的开发环节都能够满足相关要求,必须强调软件开发过程的监督审查工作,确保开发人员能够严格按照有关规范,遵循标准的流程进行软件开发,避免出现跨阶段开发的情况。同时,在每一个开发阶段完成后,都应该及时进行软件评审工作,明确各个阶段的软件开发标准,及时对存在的问题和不足进行处理。在整个软件开发过程中,必须设置专业的软件评审人员,其在保证计算机软件可靠性方面具有重要作用。通过对软件设计人员提交的软件文档进行审核,分析其是否对上一个阶段软件文档的标准进行了执行,来衡量软件开发的效果。另外,评审人员还应该加强与其他领域专业技术人员的交流和配合,以保证良好的评审效果。
3.4 做好软件测试
固然,在进行计算机软件设计和开发的过程中,可以通过强化监督管理的方式,消除各种因素的影响,减少软件中存在的缺陷和漏洞,进而提升计算机软件的可靠性。但是就实际情况而言,计算机软件本身是非常特殊的,除开比较明显的影响因素,还有很多因素非常隐蔽,不易察觉,其同样会导致软件可靠性的下降。因此,在软件开发完成,投入市场前,必须做好相应的测试工作,对软件的性能、运行效率、整体质量以及安全性、稳定性等进行测试,及时发现监督审查中遗漏的问题,并采取有效的措施进行解决,进一步提升计算机软件在实际应用中的可靠性。同时,还可以结合计算机本身的运行条件,以及网络环境,分析可能影响计算机软件可靠性的因素。需要强化对于网络的监管工作,对计算机软件的运行环境进行优化,提升软件的可靠性,确保其达到应用标准后,才能投入使用[8]。
4 结束语
总而言之,计算机软件技术的发展,推动了我国信息化进程的加快,也带动了计算机产业的进步。而在计算机软件技术的开发和应用中,受各种因素的影响,存在着不可靠性,影响了软件功能的有效发挥。对此,在软件设计环节应该充分分析各方面的影响因素,积极推动软件工程,做好软件研发工作的规范和监管,加大资金和人才的投入力度,及时发现并消除软件中存在的问题,提升软件技术的可靠性。
参考文献
[1]焦宇.浅析计算机软件技术的发展[J].信息与电脑,2015(12):46-47.
[2]贾宗璞,赵广磊.浅析计算机软件技术的发展[J].计算机光盘软件与应用,2013(18):137.
[3]红梅.现代计算机软件系统技术结构的新特点[J].内蒙古金融研究,2013(7):84-86.
[4]郑德贤.浅谈计算机软件技术的发展与应用领域[J].电子世界,2014(8):100.
[5]刘唐荣.对计算机软件技术不可靠性的几点探讨[J].通讯世界,2015(15):201.
[6]乔国荣.计算机软件技术的不可靠性分析[J].计算机光盘软件与应用,2013(5):200,202.
[7]周叔欣.对计算机软件技术不可靠性的初探[J].通讯世界,2016(12):103.