基于构件的软件工程

2024-09-19

基于构件的软件工程(精选12篇)

基于构件的软件工程 篇1

软件是信息产业的灵魂,软件工程是软件产业的灵魂。1968年由NATO(北大西洋公约组织)在德国格密斯(Garmish)举行的学术会议上正式提出“软件工程(software engineering)”这一概念以来,软件工程发展极快,取得了丰硕的成果。软件工程分为传统软件工程、面向对象软件工程、软件过程工程和构件软件工程四种。

软件工程没有一个权威的定义,比较认可的定义为:软件工程是一门交叉学科,它是解决软件问题的工程,是对软件开发、运作、维护的系统化的、有规律的、可定量的研究方法。

软件工程有明确的目标。那就是研制开发与生产出具有良好的软件质量和费用合算的产品。软件质量可用六个特性来评价:功能性、可靠性、易使用性、高效率性、可维护性、易移植性。

软件工程不同于一般工程,具体表现在以下几点。

(1)软件是逻辑产品而不是实物产品,所以费用集中在研制开发上而不在生产上。软件不会用坏、磨损、老化,但有一个过时的问题。(2)由于软件是逻辑产品,使得它的功能只能依赖于硬件和软件的运行环境以及人们对它的操作,才能得以体现。(3)软件产品的功能比一般产品的功能复杂得多。(4)软件设计比一般产品复杂得多。具体表现在:功能的多样性,实现的多样性。推动软件工程发展的原动力是提高软件质量和软件开发的生产效率。

1 传统软件工程

传统软件工程采用面向过程,即结构化程序设计方法,即有很多成功的例子,例如DOS操作系统,也有很多失败的例子,例如美国阿波罗登月飞行计划的软件错误。因为传统软件工程不能驾驭复杂系统的开发,曾经一度产生了软件危机。面对越来越复杂的软件系统,传统软件工程已经不能胜任,在实践中,人们呼唤能适应复杂系统开发的软件工程方法学和软件开发技术的诞生,面向对象软件工程应运而生。进入20世纪90年代以来,Internet飞速发展,人们碰到了另一个难题,快节奏地开发基于Web的大型应用程序,面向对象软件工程及其技术已经不能胜任,人们尝试利用基于构件的技术来解决,于是诞生了CORBA、COM及COM+、J2EE及EJB等基于构件的技术和软件开发方法。然而,今天的构件技术离人们追求的目标——软件工厂还相差甚远。

面向过程的优点:面向过程的思维方法是符合人类认识规律的,因为人们解决问题,总是一步一步进行的,其中,有顺序,条件和循环,利用这三大结构,可以解决世界上的任何问题。这些方法是优秀的,被面向对象和面向构件所吸收,成为类或构件内部实现的有力工具。面向过程的缺点:着眼于细节,不能很好地从宏观上把握系统。

2 面向对象软件工程

面向对象软件工程是运用面向对象方法,符合人类认识规律的一种软件工程。20世纪60年代后期出现了面向对象的编程语言,2 0世纪7 0年代初X e r o x公司推出了Smailtalk语言。奠定了面向对象程序设计的基础,1980年出现的Smatltalk-80标志着面向对象程序设计进入了实用阶段。自20世纪80年代中期起,人们注重于面向对象分析和设计的研究,逐步形成了面向对象软件工程方法学。典型的方法有ECoad和E.Your Don的面向对象分析和设计,GBooch的面向对象开发方法,J.Rumbaugh等人提出的对象建模技术(OMT),Jacobson的面向对象软件工程等。20世纪90年代中期,由GBooth,J.Rumbaugh、Jacobson等人发起,在Booch方法、OMT方法、OOSE方法的基础上推出了统一的建模语言(UML),1997年被国际对象组织(OMG)确定为标准的建模语言。

面向对象方法的出现受到了计算机软件界的亲睐,并成为20世纪90年代的主流开发方法。面向对象方法的优点如下。

(1)从认知学的角度来看,面向对象方法符合人们对客观世界的认识规律很长一段时间里,我们分析、设计、实现一个软件系统的过程与我们认识一个系统的过程存在着差异。例如结构化方法分析的结果是数据流图,设计的结果是模块结构,实现的结果是由程序模块组成的源程序。(2)开发的软件系统易于维护,其体系结构易于理解、扩充和修改面向对象方法开发的软件系统由对象类组成,对象的封装性很好地体现了抽象和信息隐蔽的特征。(3)面向对象方法中的继承机制有力支持软件的复用

3 构件软件工程的概念模型

构件和基于构件的方法是电子商务革命的驱动力,它们是Internet时代开发企业级解决方案的方法。在任何行业中,复杂情况通常是通过很多关键概念来解决的。这些概念是通过抽象、分解、选代、细化等方法来表达的。其中的关键是分解技术——把一个较大的问题分解成较小的、可管理的单元,这样每一个单元都是可以单独处理的,这个技术是软件工程的许多方法的核心。这些方法可以称为结构化设计,模块化编程,面向对象程序设计,基于构件的程序设计,它们产生的单元称为模块、包、对象或构件。

基于构件软件开发是历史发展的必然,基于构件的软件开发(Component Based Software Development),简称CBD。基于构件的软件工程(Component Based Software Engineering),简称CBSE。CBD追求的目标是软件的“即插即用”。回顾经典的工业化革命,不难得出一些有益的启示:功能再复杂的产品都是由大量标准的零件(领域构件)组成,零件在生产线上装配成一个产品,所有零件在产品中共同发挥作用。分工越细致,专业生产的程度越高,总体生产效率就越高。

把这些启示运用于软件开发,那就是:标准的零件就是软件生产的构件,构件在软件生产线上通过集成得到新开发的软件。

3.1 构件的分类

构件有两个层次,粗粒度构件和细粒度构件。粗粒度构件指的是基于操作系统平台的构件,已经实现即插即用的目标。例如,基于Windows平台开发的各种应用软件,Microsoft Office,Windows Media Player,Realone Player,Flash Get,金山词霸,瑞星杀毒软件等等,这些应用程序可以直接安装使用,当不再需要这些应用程序的时候,可以通过自带的卸载程序或通过控制面板将其卸载。很明显,这正是我们所讨论的软件的“即插即用”,只不过这些构件跨平台能力太差,不能直接从Windows平台移植到Unix平台、Solaris平台或其它平台;复用程度也太差,不是我们心目中最求的目标。

细粒度构件指的是可以用来组装应用程序的构件,包括通用构件和专用构件,基于构件的软件开发讨论的就是这种构件。

另一种分类是根据软件复用来进行分类的,分为广义构件和狭义构件。广义构件是指用于复用的软件实体,包括分析文档、详细设计、代码实现等。狭义构件特指二进制代码构件,可以用于组装应用程序。

3.2 CBD模型描述

基于构件的软件开发,简称CBD,足面向对象程序设计的继承和发展。一个构件由一个或多个对象经过包装构成,通过接口独立地对外提供服务。接口和硬件接口相似,有输入接口、输出接口和输入输出接口。我们看现实生活的一个例子,可以引发我们的很多思考。人是一个对象,也是经过规范包装的一个构件,其接口是眼、耳、鼻、舌、口、身,其中眼、耳、鼻、舌是输入接口,口是输出接口,身是输入输出接口。人通过输入接口接收信息和对外界的感知,通过神经传递消息,集中在大脑进行加工处理,反馈信息通过神经传递到输出接口,从而完成人对现实世界的认识和感知,完成人与人之问的沟通与协调,这样就构成了整个人类社会。

CBD也是相似的,每个构件都是由一个或多个对象经过规范包装构成的,形成标准的部件,然后在构件集成开发环境下,组装成应用程序。下面我们详细看一下CBD生存周期的概念。

基于构件的软件开发生存周期为系统分析,蓝图设计,构件的准备与生产,构件的集成与测试,使用,维护六个阶段。经过系统分析和蓝图设计之后,就必须进行构件的准备和生产,这时候,可以复用通用构件,对于特定领域的特殊构件,必须自己进行生产,实现领域内的特殊业务逻辑。系统分析的时候,采用自上而下的分析方法,识别出系统的所有需求,把整个系统分解为多个一级子模块,如果需要,再进行更细的详分,标识为二级子模块,三级子模块等等。一般来说,模块的划分不宜太深,二级就可以了,否则理解起来就很困难。当把子模块详细分解为构件之后,在构件集成开发环境下,首先进行构件设计,实现业务逻辑,然后标识接El,进行规范包装,使构件像工业上的标准零件一样。在集成开发环境下,采用和c棚似的两层界面,一层是设计界面,一层是代码界面,构件集成开发环境的成功之处在于,双击任何一个构件,能够将构件和构件代码一一对应起来,从而大大方便编程和调试程序。当把各个小构件准备好了之后,把它们集成编译为更大的构件,直至集成为一级构件,最后把一级构件组装为应用程序。

为了更加直观,可以把包装好的构件用图形界面表示出来。有的构件是独立构件,有的构件由很多小构件组装而成。

3.3 构件软件开发层次结构(图1)

参考文献

[1]朱三元,钱乐秋,宿为民.软件工程技术概论[M].北京:科学出版社,2007.

[2]R.Otte,P.Patrick,M.Roy[著],李师贤,等[译].CORBA教程[M].北京:清华大学出版社,2009.

[3]朱其亮,郑斌.CORBA原理及应用[M].北京:北京邮电大学出版社,2010.

基于构件的软件工程 篇2

1)墙承式。

是将阳台板直接搁置在墙上,其板型和跨度通常与房间楼板一致。这种支承方式结构简单,施工方便,多用于凹阳台。

2)悬挑式。

是将阳台板悬挑出外墙。为使结构合理、安全,阳台悬挑长度不宜过大,而考虑阳台的使用要求,悬挑长度又不宜过小,一般悬挑长度为1.0~1.5m,以1.2m左右最常见。悬挑式适用于挑阳台或半凹半挑阳台。按悬挑方式不同有挑梁式和挑板式两种。

①挑梁式。

是从横墙上伸出挑梁,阳台板搁置在挑梁上。挑梁压入墙内的长度一般为悬挑长度的1.5倍左右,为防止挑梁端部外露而影响美观,可增设边梁。阳台板的类型和跨度通常与房间楼板一致。挑梁式的阳台悬挑长度可适当大些,而阳台宽度应与横墙间距(即房间开间)一致。挑梁式阳台应用较广泛。

②挑板式。

是将阳台板悬挑,一般有两种做法:一种是将阳台板和墙梁现浇在一起,利用梁上部的墙体或楼板来平衡阳台板,以防止阳台倾覆。这种做法阳台底部平整,外形轻巧,阳台宽度不受房间开间限制,但梁受力复杂,阳台悬挑长度受限,一般不宜超过1.2m.另一种是将房间楼板直接向外悬挑形成阳台板。这种做法构造简单,阳台底部平整,外形轻巧,但板受力复杂,构件类型增多,由于阳台地面与室内地面标高相同,不利于排水。

1.造价工程师土建计量讲义:钢筋的加工

2.20造价工程师土建计量讲义:深基坑支护

3.年造价工程师土建计量讲义:混凝土技术

4.2017年造价工程师土建计量讲义:土料选择与填筑方法

5.2017年造价工程师土建计量知识点:墙面抹灰

6.2017年造价工程师考试土建计量讲义:木屋架

7.2017年造价工程师考试土建计量重点讲义:水泥

8.2017年造价工程师考试土建计量重点讲义:钢筋

9.2017年造价工程师考试土建计量讲义:钢结构

基于构件的测控系统设计 篇3

关键词:FPGA;PCI;构件;计算机测控系统;通用性;可维护性

中图分类号:TP302.1 文献标识码:A文章编号:1007-9599 (2011) 11-0000-01

Measurement and Control System Design Based on Component

Song Changquan

(School of Computer Science&Technology,Soochow University,Suzhou215006,China)

Abstract:Computer control system using(FPGA,Field Programmable Gate Array)and the PCI card.In the analysis of the FPGA and PCI interface card is proposed,based on the characteristics of the measure and control component in a general ideas,measurement and control system for example has been designed versatility and high maintenance computer measurement and control system.

Keywords:The FPGA;PCI;Structures;Computer measurement and control system;General;Maintainability

FPGA[1]器件及PCI卡都是目前数据采集[2]控制领域主要流行的技术之一,FPGA器件广泛应用于通信、自动控制、信息处理等诸多领域,PCI卡是用于数据采集应用的理想采集卡产品。本文针对FPGA及PCI卡的技术特点,将其按控件组合应用在计算机测控系统中。

一、计算机测控系统硬件体系结构

根据计算机测控系统[3]的要求,在硬件设计时考虑将该系统分成工业控制计算机系统、信号调理系统、控制机箱三部分进行设计。使用计算机调试系统软件进行各输入输出信号的控制和测试。

图1.计算机测控系统硬件体系结构原理框图

(一)工业控制计算机系统

工业控制计算机系统由主流计算机系统构成,可根据实际需求选择配置,在工业控制计算机中可迅速插入多个I/O卡和FPGA卡,从而提高了系统的可扩展性,并减少了维护周期。本文选用的系统硬件配置为凌华科技的计算机平台。

(二)信号调理系统

测控系统中信号调理板采用PCI接口形式,主要用于对输出故障模拟及复位信号,输入故障状态信号进行调理数字I/O板卡选用AD-LINK的PCI-7296,32位PCI总线,即插即用96路TTL兼容数字量I/O通道,端口可编程设定为输入或输出,数字量输入可用外部锁存,输出端口状态回读,板上带有8254定时器/计数器芯片,16位外部信号事件计数器,32位定时器用来产生定时器中断,状态变换中断,中断源可编程的双中断系统。

(三)控制机箱

控制机箱内部为物理电路连接,其实现的功能即为控制机箱面板所需要观测的数据指示灯和显示屏及开关控制等搭建电路连接。控制机箱外表面即为物理主控面板,通过对其安装的控制开关,控制流量或通断量;通过机箱上的电流电压表即时显示电路中控制部分的电流值和电压值,通过LED指示灯亮灭或红绿颜色变化区分显示信号的变化。

二、计算机测控系统软件体系设计

计算机调试台测试软件选用Visual Basic开发[4],它可以进行测控系统各级故障信号的模拟控制,并能显示出操作过程,各信号的状态,检测结果和检测时间,检测可以通过自动或手动完成,可将检测结果保存至计算机中。FPGA部分由VHDL[5]实现FPGA软件部分编制控制,I/O卡及其他由VB统一编程实现。

三、测控构件通用性

通过将FPGA卡及PCI卡组合构成测控构件,使得测控构件能迅速的接入到工业控制计算机中,完成信号调理和数字量控制。其特点是可针对于不同测试功能需求,将测控构件移植,在新系统中只需完成FPGA的可编程部分,配合其他板卡使用即可快速完成新的计算机测控系统设计。

四、结束语

采用FPGA器件可以将原来的电路板级产品集成为芯片级产品,从而降低了功耗,提高了可靠性,同时还可以很方便地对设计进行在线修改。PCI其自身具有快速、正确、有效、可靠性好、操作方便及连续高吞吐率(即使是大量数据)地传输等特点;将两者有效组合构成一个独立的测控构件,让计算机测控系统平台的搭建变的更加快捷方便,使其具有更高的通用性和可维护性。

参考文献:

[1]诸振勇,翁木云.FPGA设计及应用[J].陕西:西安电子科技大学出版社,2003

[2]周林.数据采集与分析技术[J].陕西:西安电子科技大学出版社,2005

[3]李江全.计算机测控系统设计与编程实现[J].北京:电子工业出版社,2008

[4]李江全.Visual Basic串口通讯与测控应用技术实战详解[J].北京:人民邮电出版社,2007

[5]勇峰,庄新敏.VHDL与硬件实现速成[J].北京:国防工业出版社,2005

基于构件软件工程的经济学分析 篇4

相对于基于构件的软件工程, 传统面向对象的软件工程主要是基于“问题-分析-抽象-分类-细化-解决”的工作流程。传统软件工程在实践中始终难以解决生产效率不高和成本难以控制的问题。软件开发经过问题定义、可行性研究、需求分析、结构化设计、实现、维护等阶段直到最后被废弃完成整个生命周期。传统面向对象的软件工程方法总是一切从零开始, 一砖一瓦的构建高楼大厦, 难免显得经济性不够。传统软件工程对项目解决方案的变更和问题的重新定义也缺少快速应对的措施和策略, 因为这个原因导致整个开发失败的案例屡见不鲜。

基于构件的软件产品开发是将大型软件产品开发转化为系统架构开发、构件分析、提取、开发和集成。构件的集成机制 (构架技术) , 涉及到构件的描述、体系结构、消息通信等多种技术。构件的分析、提取工作需要通过不断分析领域内的共性、个性的特征来完成。构件化软件开发, 能有效改变原来应用软件开发积累少、代码复用性低、开发周期长的状况, 从质量、生产率及成本等方面提升软件开发的经济性。

2 经济性学视角的构件软件开发

(1) 基于构件软件工程的质量成本与质量收益。

软件的质量由软件的内在质量和顾客满意度两方面决定。相对应引发软件质量缺陷也是两部分构成的:一是技术性缺陷, 既由于软件开发人员在开发过程中的技术原因或失误造成的缺陷, 主要通过BUG发生率、千行误码率表示;二是由于软件开发人员与客户的沟通不良, 考虑不周全等原因造成的, 属功能性缺陷。理想情况下, 为了复用而开发的软件构件将被验证为完全正确且不含缺陷的。当然, 实际上缺陷还是会出现的。然而, 随着时间推移, 软件构件在复用中缺陷会被发现并消除, 构件的质量不断改善。根据美国惠普公司所做的研究, 被复用的代码的平均缺陷率是每千行代码0.9个缺陷, 而新开发代码的平均缺陷率是每千行代码4.1个。通过对一个包含68%的复用代码的应用系统的分析显示, 其平均缺陷率是每千行代码2.0个缺陷, 相对于不使用复用开发的系统, 对期望的缺陷率有51%的改善。而在功能性缺陷方面, 构件软件开发虽然与传统软件工程存在同样的困难与风险, 但是显然构件软件开发在通过再分析与再设计快速提高软件质量上有很大优势。

传统质量成本理论将质量成本分为预防成本、鉴定成本、内部损失成本、外部损失成本四类。前两类被统一称作符合成本, 既确保产品满足标准和规范要求所付出的代价;后两类被称作非符合性成本或损失成本, 既因为产品不符合质量标准和规范所造成的损失。令软件质量水平为x, x⊂[0, 1], 设符合性成本为Cm, 非符合性成本为Cn, 质量总成本为:Cq=Cm+Cn, C1与x成反比, Cn与x成正比。设m为符合性成本的比例系数, n为非符合性成本的比例系数 (m+n=1) , 则有:

undefined

当undefined时, Cq有最小值undefined, 既最小质量成本。

软件的质量收益来自三方面:一是生产者的质量收益, 包括质量提高获得的销售价格收入、成本获得的收入、质量提高获得的荣誉及由此带来的收入等。二是消费者的质量收益, 主要有软件产品日常用费的节约带来的经济收益;软件产品日常维护费用的节约带来的经济收益;软件产品可行性带来的经济收益;产品使用寿命带来的经济收益等。三是社会的质量收益, 软件质量直接或间接影响的其它部门或企业产生的经济收益和效果, 以及质量影响传递获得的经济和社会价值。

软件的质量的经济性主要体现在质量水平、质量成本、质量收益三者的关系。对于一个可持续的软件开发企业而言, 当质量水平很低时, 质量控制的符合成本很低, 但是低质量带来的负面影响, 既非符合成本是很巨大的, 整体质量成本高, 此时质量收益也处在很低的水平。随着质量水平的提高, 符合成本上升, 非符合成本大幅下降, 质量成本呈下降趋势。当质量水平上升到一定高度, 非符合成本已经很低, 质量成本开始上升。而质量收益是始终随质量水平上升而上升的。为了更直观表明软件质量的经济性, 不妨引入质量利润的概念, 令质量利润=质量收益-质量成本, 三者与质量水平的关系如下图:

随着质量水平的提高, 质量利润转负为正并不断增加, 当达到一定水平时, 质量收益的边际效益下降, 质量成本仍持续增长。但即便此时, 提高质量水平仍然能够提高软件开发的质量利润。传统软件工程方法在达到一定质量水平xo后再想提高已经非常困难, 而构件化的软件开发可以将软件质量提升到新的高度xc。也就是说, 构件化软件开发在理论上能获得更高的质量收益和质量利润。

(2) 构件软件开发生产率与成本的变更模型。

构件软件开发的典型过程模型分为领域工程和基于构件的开发两个子工程。领域工程创建应用领域的领域模型和结构模型, 该模型是构件软件开发中分析用户需求的基础。基于构件的开发则是将构建的模型进一步进行细化并选用适当的构件搭建并完成应用软件。

在可复用软件构件被应用于软件开发的全过程中时, 对开发系统所必需的计划、模型、文档、代码和数据的创建工作将花费较少的时间, 其结果是用较少的投入给客户提供了相同级别的功能, 因此生产率得到了改善, 成本也相应降低。然而, 构建领域模型和结构模型, 代替传统软件开发针对特定问题的分析与模型设计, 这并不是一个简单的工作。应该看到, 基于构件的软件开发在起始阶段的生产率并不高, 构件库的创建成本很大, 构件库的积累也需要一段时间。可复用构件的开发因为要考虑质量、通用性等因素, 开发周期和人物力投入都超过了传统软件工程。考虑一个新系统的开发, 其全部工作量由开发和构造新软件构件的工作量Enew、对复用构件进行合格性检验所需工作量Equal、对复用构件进行适应性修改所需工作量Eadapt、集成所需工作量Eint四部分构成。

全部工作量E=Enew+Equal+Eadapl+Eint

合格性检验、适应性修改和集成所需的成本可以通过计算各控件在历次复用中的平均值得到, 既Equal、Eadapl、Eint的成本是已知并可控制的。

考虑用构件软件工程方法开发N个应用系统每次成本为Cn (n=1, 2, 3 Λ N) , 传统面向对象软件工程开发这N个应用系统的成本为C′n, 平均值为undefined。创建和管理构件库的初始成本C0通常都是大于undefined的, 在此取C0是undefined的1.8倍设为默认值。ck (k=1, 2, 3Λ i) 为构件库中i个构件的创建与管理成本, tk (k=1, 2, 3 Λ i) 为每个构件的总复用次数, 则:

undefined

R为复用度, R=复用构件的总规模/应用系统的总规模。设F为复用一个构件的相关成本系数, F=复用某个构件的成本/全新开发某项功能的成本, 根据统计, F的平均值约为0.2;tnk是第n个应用系统中构件ck的复用次数, 且undefined, 有

undefined

经过N次开发的合计成本:

undefined取平均值:

undefined

将构件复用的相关成本系数F取定值0.2则undefined, 可见, 基于构件软件开发的平均成本与构件库被使用的次数成反比, 与软件的复用度成线性关系。设软件的复用度为0.6, 则当N>3时, undefined, 既当构件库被复用3次以上时, 可收回创建和管理构件库的投资成本。

3 结论与展望

根据以上分析, 通过建立和不断丰富构件库并实现软件构件的复用是对软件工程实践的良性积累, 基于构件的软件工程方法是提高软件开发经济性的可行途径。当然, 基于构件的软件工程同样也面临着一些问题和矛盾, 需要在实践中探索和解决。首先是构件的设计要求尽量完善和应用系统整体设计力求简单的矛盾;其次是构件库的的不断扩大带来管理成本升高和整体利用率下降的问题;最后是如何解决技术进步引起的构件库升级。虽然复用一直都存在, 但真正基于构件的软件开发实践还很有限, 然而, 随着软件开发技术的发展与前进, 软件开发观念的变革与创新, 软件构件的开发与复用技术必然会得到更多的尝试和更大的发展。应用成熟的基于构件软件工程方法, 全面提升应用软件开发的经济收益是很值得期待的。

参考文献

[1]Roger S.Pressman.软件工程——实践者的研究方法[M].郑人杰, 马素霞等译, 2007.

[2]封莉.软件开发的质量及其经济性研究[N].南京航空航天大学硕士学位论文.2007.

金属结构工程构件安装说明 篇5

1、本章未涉及的相关内容,按混凝土及钢筋混凝土构件安装定额的有关规定执行,

2、网架安装如需搭设脚手架,可按脚手架相应定额执行,

3、钢柱安装在钢筋混凝土柱上,其人工、机械乘以系数1.43。

4、高层金属构件拼装、安装适用于檐高20m以上的金属结构构件。

基于构件的软件工程 篇6

【关键词】 业务构件;信息系统;动态建模

一、前言

动态建模思想和方法体系的理论框架由德国经济学家提出,核心思想是企业需要建立灵活的管理和组织形式,通过业务流程的不断调整和优化,来适应外部变化的环境。

本文将软件工程中的构件理论引入到企业动态建模的方法体系中来,研究的重点更加关注于企业模型向实际应用层面的概念映射,能够进一步提升模型的灵活性、稳定性和可扩展性,并建立了一套基于业务构件的企业动态建模方法体系。

二、企业动态建模(DEM)和业务构件

企业模型是一项支持企业集成与优化的共性技术,是对企业系统中与给定目标有关的特性加以抽象表达的工具方法。借助企业模型,我们可以充分认识、完整描述企业行为。传统的建模方式都是以多视图、全方位的体系结构来描述企业模型,通过各个角度之间的关联将它们整合到一起,从而获得该企业整体的概念模型。随着计算机和信息技术应用范围的不断扩大,企业的管理、经营模式也在不断变化。但依据这些建模方法和相应软件下建立起来的ERP过于复杂。在这种背景下,支持业务流程重组和信息系统灵活性的动态建模技术和方法体系逐步建立起来,它强调为企业建立通用的实施与管理框架,即参考企业模型,在强调通用时,也强调领域/行业特性建模。

构件建模理论最早来源于软件复用的思想,软件复用是为克服软件危机而提出的解决方案。构件是目前被认为软件复用最有效的途径之一,构件是可复用的、独立的、市场化的软件,这种软件能够通过某种途径(比如通过其他软件的辅助)为用户提供服务,并且在开发过程中能够灵活地配置,即可被灵活应用到各个相关系统、修改或替代。而可复用构件(Reusable Component)是指具有相对独立的功能和可复用价值的构件。构件理论的核心是建立领域内统一的分析、设计标准,从而有效地解决目前软件行业所面临的诸多问题。

三、基于业务构件的动态企业建模

1.企业模型框架设计

在企业模型宏观框架上,本文将企业模型分为横向和纵向两个方面,首先在纵向建立模型框架,主要由战略层、过程层、业务组织层、业务功能层、物理数据层组成。企业战略层的职能主要是确定企业战略、产品发展方向和业务领域,同时应用战略一致性模型建立与企业战略规划相一致的企业信息化战略框架。主要通过将战略层的企业战略分解到企业信息框架的过程、业务层和底层物理数据,各层面依据宏观战略和自身情况进一步明确目标规划,并实施目标任务的分解,直至各层面不可再分的基本单元为止,从而实现企业战略与信息框架的全面匹配。

在企业战略的基础上建立的信息系统框架模型,按照传统信息系统的子系统功能进行横向划分。此外,依据构件架构的特点,引入知识管理模块、日志管理模块和安全控制管理模块。知识管理模块对系统知识进行整理,同时通过对存储的文献、文档和管理日志进行数据挖掘,获得新的知识。整个信息系统架构图如图1所示:

过程层是在企业战略规划的指导下,对业务过程的建模描述。业务层主要分为业务组织层和业务功能层。业务组织是对企业各部门组织结构的建模描述,业务功能层则是对在企业战略规划下对业务流程进行分解得到的基本业务操作单元的建模描述。物理数据层是将业务模型映射到信息系统实际应用的连接纽带,侧重于数据库建模。企业业务构件的设计必须遵循以下的原则。

(1)业务构件识别是建立一系列分类的特征和标准,依据构件内部聚合度高,构件之间耦合度低的原则,对业务操作单元进行分类,并对被划分类进行独立设计和封装的过程。

(2)业务构件的语义智能性。能够为可快速重组信息系统的开发提供理论和技术上的支持,当业务变动时,系统维护人员,甚至是用户都可以通过简易的操作来完成相应信息系统的相应转变。

(3)强调标准和建模的规范化,复杂系统的建模及其实施是需要团队合作的,这就更加强调需要统一的、简洁的交流标准便于团队不同专业背景成员之间的相互交流。

2.基于构件理论的业务模型动态建模机制

对于已经被识别出来的业务构件模型,我们需要分别从数据视图、过程视图、组织视图、功能视图和管理控制视图建立业务构件内部和构件之间相互联系的模型体系。在新的建模指导思想下,我们对现有模型进行改进。

(1)数据视图反映业务过程中角色对数据、资源的访问和操作,反映重要数据如订单的流向,但缺乏动态建模的思想。本文引入软件工程中的反射机制和代理机制建立统一的业务数据模型(DataTransferObject),反射机制主要指类可以修改自身的属性和方法并生成实例。即首先建立一个代理类模型,该类模型主要由获取业务资源模型GetData(),资源设置模型Store(),反射机制模型EchoModel()和资源传输模型TransUtil()组成。用数学语言描述如下所示:

DTO(rs,Object)={GetData(),Store(),EchoModel(DTO,num),TransUtil(Object,SetName,Vzlue)}其中rs表示待传输的业务数据、资源集,Object表示传输目的地,为其他的业务对象。EchoModel(DTO)表示应用反射机制EchoMode,模型DTO可以依据需要传输业务数据集rs的属性数量num在自身内部生成相应的元数据集SetName及其相应值Value集合,最后通过TransUtil将值集合Value进行传输。

(2)过程视图对企业模型的业务流程进行描述,目前主要采用工作流建模技术,其主要特点是将业务过程从应用程序中提取出来,从而提升整体的柔性。在业务构件理论中,AntoniaAlbani曾指出实施基于构件的软件开发(Component-BasedSoftwareDevelopment),需要辨识实际业务流程中具有高度可重用性的单元,即业务流程构件(BusinessProcessComponent),业务流程构件是对业务构件具体概念的封装,在建模中,它包括构件名称(Name),编号(Id),步骤(Step),步骤状态(StepStatus),步骤中的活动(Activity),活动状态(ActivityStatus)。以业务过程构件发布询价汇总表GatherPriceInfo为例,其模型表示如下:

{Name=GatherPriceInfo,Id=GatherPriceInfo,

{StepId=1,Name=WaitForVia,Status=Waiting//步骤1为等待申请被通过,状态为等待中

{ActivityId=1,Name=SendApply,Status=Finished//步骤1包含活动SendApply,该活动已完成

Describe=”SendApplicationtothesecondadmin”//活动功能描述

MappingPath=””//活动在业务构件管理中心模型中的路径映射

Method=”SendForAdmin”}//活动对业务构件管理中心模型的命令 }}

(3)组织视图描述的是企业内部组织单元以及人员的组织关系。组织视图一般由人员、角色和操作组成,三者之间是一种动态关联的关系,在组织结构中,人员可以扮演多种角色,不同的角色可以被赋予不同权限的操作,扮演相关角色的人员则可以行使相应的操作。

(4)功能视图是对具体业务功能的建模,业务功能对应业务过程构件的Activity,是一个或若干操作单元的集成。在建模的时候,我们要设计构件接口和构件功能实体,接口用来接收命令,实体则依据命令执行相应的任务。考虑到业务构件单元的可复用性,我们引入继承的概念,首先将众多业务构件模型通用的属性或方法抽象出来,用一个抽象类模型进行封装。比如具有初级权限的供应商,它的模型描述如下所示:

PrimarySupplier={Name,Id,Company,Address,Contact,Operation={……}}

这是其它更高级供应商都具备的基本信息,属于通用部分,因此,可以将之抽象出来生成GeneralSupplier。初级供应商则可表示:

PrimarySupplier={inheritGeneralSupplier}//inherit表示继承GeneralSupplier

(5)管理控制视图是对以上4个视图的综合控制管理,所有识别出来的业务构件、业务过程构件都需要在管理控制视图中被配置,一个业务构件在管理控制视图中需要提供其名称、编号、功能、类型匹配参数、属性以及与其它业务构件的逻辑关系集。

四、实例

电子政府采购是我国电子商务“十一五规划”的重点试验项目之一,对于政府的大型工程项目,一般采用公开招标的方式,针对不同项目的特点,政府采购中心需要在遵守政府采购法的前提下设计出不同的招标流程。本文采用基于业务构件的动态建模的方法对该流程进行建模,依据前文的建模方法,应用Appfuse开发平台、OsWorkflow开源工作流和Mysql数据库实现系统原型。

首先通过领域分析,研究公开招标所涉及不同项目的行业特点,从长远的发展规划提出总体的战略目标,在此目标的指导下,将总目标分解为办公管理子系统、财务管理子系统、公开招标管理子系统、知识管理子系统、日志管理子系统和安全控制管理子系统的分目标,这里以公开招标管理子系统建模为例进行介绍,对该业务过程分别进行基于业务构件的信息系统建模。

在过程建模方面,政府采购公开招标总体流程应分为:申请招标、发布标书、制作报价汇总单、制作专家评分表、抽取专家、召开开标大会、专家议标、供应商填写问题澄清表、专家打分、生成综合分数汇总表、确定中标机构。依据分流程之间的耦合关联度,将其分别划分为业务过程构件,并进行模型设计。依据每个业务过程构件模型定义的活动和活动关联,进行业务功能构件设计,参照不同行业的特点,对变动较大的业务功能如制作专家评分表、专家打分表进行构件化设计。模型关系如图2所示:

五、结论

企业动态建模的理论很多,但是如何实现企业模型向计算机支撑平台映射、实现自动装配的研究相对较少。本文以此为切入点,在原有建模理论的基础上,引入构件理论建立一种更加面向实际应用系统的动态建模体系,使得企业模型更具有柔性。

后续的研究工作应包括通过实践进一步完善该建模体系,在此基础上进行建模工具的开发与设计。同时,依据不同行业的特点,建立大量的企业参考模型库和标准可复用构件库,从而能够更好地为企业变革服务。

参考文献:

[1]范玉顺,胡耀光.企业信息化规划的基本框架与方法.新技术新工艺,2004,(9):2-7

[2]杨芙清,构件技术引领软件开发新潮流[J].中国计算机用户,2005,6:13

基于软件构件的软件开发流程浅析 篇7

1构件定义

构件主要指软件系统中的单个元素, 自身具备独立、可替换、满足功能和多次使用的特征;也是软件重复使用时, 可以的准确被识别的软件实体, 对此借助软件的独立和可重复使用的功能形式, 构件完全被用来进行软件研发, 使其外界的访问, 可以利用构件提供的指定接口进行信息交换;构件之间会通过标准的接口进行信息转换, 从而更好的保证软件开发的质量。同时基于构件软件开发, 也应当具备应用程序是由构件组装, 提供独立服务, 以及通用构件设施和服务等相关的要素。

2软件开发形式

基于软件构件的软件开发流程, 主要体现在构件定制、构件独立以及接口统一几方面, 其中构件定制, 主要是指基于软件构件的软件开发, 利用到构件或是面向构件, 都是事前明确功能和编制好的, 同时软件对于构件不同功能的需求, 也可以通过构件版本的选择, 从而实现功能拓展的目的。其中构件独立, 主要是指将构件进行分解, 这样就可以有效的避免构件难以维护的情况出现。其中接口通过统一, 主要是指软件要想实现跨平台的交互, 可以通过指定的接口, 从而有效的突破硬件设备, 以及空间等方面的限制。

3构建模型分析

因为基于软件构件的软件开发, 是在理想构件模型基础之上进行操作的, 对此对于目前常用的几种构件模型分析, 是非常有必要的;其理想的构件模型如下图所示;

目前常用的构件模型, 主要包括OMG组织、SUN、Microsoft方面;其中OMG组织中的CORBA[1], 是基于开放平台制定的对象代理体系, 同时其分布计算技术们, 更是多种厂商所支持的技术;自身具有支持性高、语言开发、系统平台独立, 以及模型完整、效率高的特点。其中SUN中Java2技术, 具有语言开发以及满足不同的业务需求、简化构件服务器繁琐, 以及应用广泛的特点。其中Microsoft中COM构件模型, 实现了模型之间的相互操作, 同时自身也是标准的构件接口, 有效的用远程技术, 使其构件技术被广泛的应用。

4基于软件构件的软件开发流程研究

基于软件构件的软件开发流程, 主要包括整体框架设计、构件库建立、获取构件、构件调整以及重组安装等过程。

4.1整体框架设计

对于其整体框架设计, 首先要对于业务需求进行有效的分析, 然后找出与将要设计的软件功能需求的共性, 然后将功能构件从系统中进行分解, 最户将开发软件系统构件化。

4.2构件库建立

构件库建立是为了使构件更好的符合软件开发需求, 从而将构件进行统一管理, 同时构件库对于软件的重复使用, 起到支持、描述分类、保存等作用;从而更好的保证软件开发的效率。

4.3获取构件

需求分析后的构件, 会将满足应用环境的构件选取出来, 并进行适当的修改, 最后使其组装到将要开发的软件系统中。其中构件的获取, 可以通过发现阶段、评估阶段, 利用以往开发过的构件, 按照系统开发的需求进行选取, 或是利用当前开发的系统功能模式, 对于构件进行开发和获取, 再就是利用购买、利用网络资源进行构件获取。

4.4构件调整

当构件获取后, 为了是获取的构件更加的满足系统开发的功能需求, 使其符合设计规则, 对此需要对于构件的功能, 进行一系列的调整;调整的形式分为白盒法、黑盒法以及灰盒法, 其中白盒法的主要形式, 是通过对于构件源码的修改, 使其构件之间的冲突降低, 但是对于源码的调整会影响其使用特性, 给后期维护造成影响, 对此进行有效的维护是非常有必要的。其中黑盒法以及灰盒法, 是将源码进行保留, 提供构建的扩展机制, 或是提供可编接口。

4.5构件的组装

构件库中的构件按照应用环境进行调整, 然后将构件的端口进行相互连接, 或者将构件与开发软件元素进行连接, 使其更好的进行软件开发;每个构件的作用发挥, 是在与群体构件组合之后发挥功能的;对此在进行系统研发时要将单个构件进行整合, 利用可以容纳不同性质构件的框架进行管理;同时对于构件的安装, 可将通用性、功能性强的构件, 布置在中央数据服务器上;最后进行粘接代码的编制的工作。

5总结

综上所述, 发现软件开发是一项复杂且繁琐的过程, 相关设计人员不仅要掌握软件构件的基本性能, 还要做好软件开发需求调研分析, 工作任务繁重并且头绪杂乱。本文对基于软件构件的软件开发的流程进行梳理, 开发人员可以参照整体框架设计、构件库建立、获取构件、构件调整以及重组安装等步骤进行标准化实施, 一方面可以减轻开发人员繁杂的工作量, 另一方面也能够更好的保证软件开发的质量和效率, 希望对软件开发者有所帮助。

摘要:随着我国科学技术不断的发展, 软件开发的理论和流程, 以及构件技术也在逐渐的完善和发展, 而基于软件构件技的软件开发, 可以更好的利用构件技术的功能, 使其软件开发的成本有效的降低, 同时软件的系统的安全性、可维护性也能得到可靠的保障;对此本文结合构件定义, 通过对软件开发形式和构建模型的分析, 最后梳理出基于软件构件的开发流程, 希望对于软件工程的发展, 有着积极促进的作用。

关键词:软件构件,软件开发

参考文献

[1]田容雨.基于软件构件技术的Web系统开发平台的研究[D].山东大学, 2011.

[2]叶伟.构件化软件开发及系统测试技术探究[J].计算机光盘软件与应用, 2012, 03:176-177.

[3]沈拴喜.浅谈基于构件的软件开发方法和技术[J].计算机光盘软件与应用, 2014, 15:75-76.

论基于构件的软件开发 篇8

由于此平台是一个综合性的在线式基于WEB的远程技术支持平台, 存储着大量信息数据, 提供任务发布和查询, 拓扑图查询, 专家分类查询, 软件支持下载, BBS, VOD视频等服务, 功能的多样化, 必然会在软件开发中出现重复开发的现象, 所以在开发初期我从该系统的需求分析入手, 着重考虑了软件复用, 在开发过程中采用了基于构件的软件开发方法。我将软件设计为B/S结构, 三层体系架构:用户界面层, 应用逻辑层, 数据库层。用户界面层考虑到用户的易用等方面, 用的是浏览器 (如IE等) , 通过ASP.NET语言来实现同应用逻辑层构件交互;应用逻辑层用来处理各种应用功能的实现, 负责事务处理, 主要通过使用COM组件方式实现, 以构建形式进行设计开发, 考虑到以后的扩展和软件的复用性, 大大的提高了开发效率;数据库层用SQL SERVER来实现。

结合我部门的实际情况, 我部门现有的各级软件系统都是基于Windows系列平台, 且开发人员对COM组件技术也比较熟悉, 对开发语言VB.NET也很熟悉, 在这里我选择Microsoft应用服务器的解决方案, 用windows server 2003作为应用服务器, 确定使用Microsoft的COM组件技术来开发该平台。用SQL SERVER 2005为后台数据库, 用ASP.NET+IIS6.0来架构网站。

由于COM组件既可以被嵌入动态WEB页面, 还可以在LAN或桌面环境的VB.NET, VC.NET等应用中使用。另外该组件之间是彼此独立的。当应用需求发生变更时, 可能需要更换中间层的个别COM组件, 但并不影响其他组件的继续使用。组件具有若干对外接口 (属性和方法) , 可以根据不同的应用需求, 来选择使用不同的接口。即使不再使用某些接口时, COM组件本身仍然可以继续使用。同一COM组件可以在不同的应用环境中重复使用。

由于该系统以在线服务支持为主, 主要包括了用户交互操作, 资料输入, 数值处理, 数据存储等几个方面, 我们依据平台的主要功能, 为了节省开发时间和提高维护效率, 我决定把公用的代码模块都作成了组件, 例如把记录操作 (如记录的删除, 增加, 修改等) , 数据库操作, 查询做成用户管理组件, 把用户身份认证和用户类型识别作成用户管理组件, 把所有实现与数据库的连接作成连接组件, 把用户的错误操作, 与系统的交互出错等作成错误处理组件。对于各组件采用VB6语言进行编写, 并写成DLL文件, 同时注册成为COM程序, 供各个组件调用。在数据库连接方面, 我们采用了ADO技术。由于ADO采用了OLE-DB技术, 使能访问各式各样的数据并提高了访问性能。

在该平台开发过程中, 主要设计和实现了以下一些COM组件:

(1) 用户管理组件, 包括身份认证功能

我们主要定制COM组件用户管理组件User Check.dll进行用户管理处理。该组件主要完成两个功能:一是身份认证功能, 主要是提供用户登录时验明身份, 保证应用的安全性。二是根据用户所输入的账户名确定该用户的类别。

因此, 该组件具有两个接口, 每个接口代表组件的某个属性或方法。对用户的登录请求作出相应的处理:如果是普通用户登录则转入普通用户平台, 如果是管理员登录就转入管理员平台。

(2) 查询和提交信息组件

我们主要制定COM组件Query Sys.dll进行查询和提交信息处理。该组件主要完成两个功能:一是提供查询相关信息;二是提交相关信息。

该组件有两个接口, 每个接口代表组件的某个属性和方法。如果用户的请求是查询信息功能, 则将查询信息请求作出相应的处理, 并将查询结果集返回给用户。如果用户的请求是提交注册信息, 则将提交信息请求做出相应处理, 并将信息提交提示返回给用户。

(3) 连接组件

我们主要定制COM组件Conector.dll, 该组件主要完成与数据库的连接。该组件具有一个接口, 那就是确定数据源, 以便自动连接后台数据库。

(4) 错误处理组件

我们主要定制COM组件Cerror.dll, 该组件主要确定错误类集, 该组件具有一个接口, 主要是输出错误信息, 方便用户排错。

我们把编译好的组件, 将其在MST中注册, 并将其分布在服务器上, 这样就可以在设计平台过程中进行调用这些组件了。在本系统中, 我们通过以下几种方式把组件集成到系统中来:

一是连接集成, 即我们将组件直接嵌入ASP.NET主页中, 即在ASP.NET脚本中通过SET对象名=Server.Create Object (“类名”) 来引用, 使此二进制组件可以运行于服务器端。

二是容器集成, 即如果一个组件需要调用另一个组件时, 就在需调用的组件中引用另一个组件的方法。例如在使用查询和提交信息组件时就需要先调用连接组件。

我们结合连接集成和容器集成两种方式来组装系统, 以登录界面为例, 在客户端我们只提供两个输入项和一个提交信息的功能按钮, 主要通过ASP.NET来实现。在服务器端, 主要根据用户输入的信息来进行相应的处理, 这就要调用各种组件。如果用户用错误的账号和用户名来登录, 则系统调用用户管理组件, 错误处理组件和连接组件, 返回非法用户的信息。如果用户以合法的身份登录进入用户平台, 这就要调用用户管理组件, 连接组件。如果管理员以合法的身份登录进入管理员平台, 也要调用用户管理组件, 连接组件。

我们采用COM组件技术进行开发, 给我们带来了很大的好处, 例如:减少了重复输入代码的工件, 缩短了软件的开发周期;同时, 在进行系统维护时, 我们只关心组件的接口参数, 而不用再考虑组件内部的具体实现, 提高了系统的可维护性。在以后的工作中, 如果我们要扩展某些功能时, 也可以重复利用这些组件, 提高了系统的可复用性。

但在运行中, 我们也发现了一此不足之处:由于在ASP.NET中运行的COM组件是二进制代码, 当COM组件工作出错时, ASP.NET不能指出COM组件发生错误的具体位置, 只能简单显示对象创建不成功。这样就给我们在调试该平台过程中增加了难度。

综上所述, 经过整个项目组精心准备和严密实施, 该项目现在已圆满完成, 得到用户的一致好评。回顾项目的实施过程, 我体会最深的是, 随着基于构件技术开发软件的成功实施, 我们在享受它带来的便利的同时, 也要注重企业内部的构件积累。我想, 随着构件技术的不断发展, 标准的构件体系与规范化的建立, 软件企业一定会迎来快速的发展。

摘要:2007年下半年, 我参加了内蒙古自治区西部区**市一家三甲医院远程医疗会诊技术服务平台的项目开发, 担任系统平台的设计和开发工作, 该项目主要是为了充分发挥医疗专家的作用, 使他们能够为更多的普通老百姓看病而开发设计的, 它是一个在线式的远程服务平台。在项目的开发过程中, 我充分的进行基于构件的软件开发, 考虑到软件复用和以后的扩展等方面, 文中介绍了构件平台的选择, 几种COM构件的开发, 平台的实现过程。基于构件的软件开发大大提高了软件的质量, 缩短了开发周期。该项目现在已圆满完成, 得到用户的一致好评。但现在看来, 在开发过程中也出现了一些不足, 有待改进。随着构件技术的不断发展, 标准的构件体系与规范化的建立, 软件企业一定会迎来快速的发展。

基于构件的软件开发研究 篇9

随着软件需求的激增, 软件的规模和复杂度不断增大。但软件开发效率低下, 大量人力物力财力被浪费在重复开发上。软件复用被认为是解决"软件危机"可行的、现实的解决方案, 而软件构件技术是软件复用的核心技术。

2 基于构件的软件开发

软件复用的概念是由McI1roy在1968年的NATO软件工程会议上提出的。McIlroy提出了发展以可复用源代码软件构件为基础的软件工业和利用COTS (commercial off-the-shelf) 构件工业化生产软件的观点[1]。它不仅包括对软件编码的复用还包括对软件生产过程中其它劳动成果的复用, 如项目计划书、可行性报告、需求分析、概要设计、详细设计、测试用例、文档与使用手册等。通常, 把这种可复用的元素称做软构件, 可复用的软件元素越大, 可复用的粒度越大。

因此应用系统的开发不再采用一切从零开始的模式, 而是以已有的工作为基础, 充分利用过去应用系统开发中积累的知识和经验, 从而将开发的重点集中在特有构成成分上。由于软件构件大都经过严格的质量认证和在实际运行环境中得到检验, 因此软件复用技术有助于改善软件质量。另外大量使用软件构件, 软件的灵活性和标准化程度也可以得到提高。

构件是具有内部结构和功能的软件构成元素, 可通过标准接口独立提供特定服务, 并且可由一些连接器及相关规则与其它构件组装成符合要求的新软件或构件。从抽象程度来看, 面向对象技术已达到了类级复用, 因为它是以类为封装单位的。但这样的复用粒度还太小, 不足以解决异构互操作和效率更高的复用。构件将抽象的程度提到一个更高的层次, 它是对一组类的组合进行封装, 并代表完成一个或多个功能的特定服务, 也为用户提供了多个接口。整个构件隐藏了具体的实现, 只用接口对外提供服务。

因此, 在基于构件的软件开发方法下, 程序开发模式也相应地发生了根本变化, 不再是“算法+数据结构”, 而是“构件开发+基于构架指导的构件组装”。基于构件的软件开发过程 (component-based software development, 简称CBSD) 如下图1所示, 在此过程中有五个主要的组成部分:需求分析、构件库、构件的获取、构件的复用、构件的组装[2]。

与传统的软件开发方法比较, CBSD有以下特点:

(1) 构件可以方便地集成于框架中, 不用修改代码, 也不用重新编译, 真正实现即插即用。

(2) 构件的接口和实现是分离的。构件通过接口实现与其他构件和框架的交互, 构件的具体实现被封装在内部, 组装者只需关心接口, 不必知道其实现的细节。

(3) 接口具有一定的稳定性。构件的接口一经定义就不能被修改。构件使用者一旦获得某接口的某项服务, 这一行为将是长期有效的。这就为系统开发者开发工作的稳定性提供了极大的便利。构件的接口应遵循严格的标准, 这也是构件技术成熟的标志之一。

(4) 构件应具有易扩充性。每个构件都是独立、自主的模块, 各构件间通过信息传送提供服务。但应该可以通过增加新的接口或新的构件来实现系统功能, 而不影响原构件。

计算机软件开发技术从面向对象技术 (OO) 和分布式面向对象技术 (DOO) 发展到软件构件技术, 并向构件技术方向演变, 软构件以至组件技术为应用软件产品化提供了理论基础, 这是应用软件产业化的基本方向。

3 构件的获取、管理与复用

存在大量的可复用的构件是有效地使用复用技术的前提。同时还要对大量构件进行有效的管理, 实现构件快速方便地存储、检索和提取, 是成功复用构件的保证。

3.1 构件的获取

通过对可复用信息与领域的分析, 可以得到构件。可复用信息依赖于特定的问题和特定的问题解决方法, 具有领域特定性。为此, 在识别、获取和表示可复用信息时, 应采用面向领域的策略。领域的需求具有一定的稳定性使得获取的信息可以在较长时间内多次复用。领域工程是一组相似或相近系统的应用工程建立基本能力和必备基础的过程。领域工程可划分为领域分析、领域设计和领域实现等多个活动, 活动和结果如下图2所示[3]。

在建立CBSD中, 构件获取可以有多种不同的途径:

(1) 从现有构件中获得符合要求的构件, 直接使用或作适应性修改, 得到可复用的构件。

(2) 通过遗留工程, 将具有潜在复用价值的构件提取出来, 得到可复用的构件。

(3) 从市场上购买现成的商业构件, 即COTS构件。

(4) 开发新的符合要求的构件。

在决定构件获取途径时, 开发者必须考虑不同方式获取构件的一次性成本和以后的维护成本。目前市场上已经有大量面向GUI、数据库和网络的VBX与Active控件、JavaBean和Delphi构件, 以及众多的类库、DLL接口和API, 这些源代码和目标代码大大提高了程序员的工作效率。

3.2 构件的管理

对大量的构件进行有效的管理, 以方便构件的存储、检索和提取, 是成功复用构件的必要保证。构件管理的内容包括构件描述、构件分类、构件库、人员及权限管理和用户意见反馈。其中, 构件的分类和构件库是构件管理的重点内容。

(1) 构件的分类

构件的分类至关重要, 只有合理的分类, 才能实现构件的便捷查找和有效复用。面向对象的概念由于符合事物的规律, 已经深入到各个领域。如果开发者使用面向对象的方法来对构件进行分类, 构件可以分为:面向用户的构件 (用于界面和程序外壳包装、接收用户的控制) 、面向OS内核的构件 (用于操作特定系统来提供服务) 、面向数据库的构件 (用于存取相关信息) 、面向网络的构件 (用于和Internet打交道) 。如果开发者使用面向领域的方法来对构件进行分类, 一个应用系统通常应该包括三类构件:通用基本构件 (如基本数据结构、用户界面元素等) 、领域共性构件 (领域的共性构成成分) 、应用专用构件 (应用系统的特有构成成分) 。

(2) 构件库的建立和管理

复用软件构件有两个前提条件:所需的构件已经存在和复用者能方便地找到所需的构件。由于软件构件蕴涵了大量的信息, 开发者要对其准确、简洁地描述是困难的。如果没有一个统一的场所对其进行统一的描述包装, 大规模的软件复用是不可能实现的, 所以建立大规模的公共构件库是必须的。简单来说, 构件库是一个对软件构件统一进行形式化包装、分类描述、存储管理、检索浏览的场所, 是大范围内、系统化实施软件复用的必备基础设施。

在CBSD中, 构件库管理系统是一个至关重要的部分。构件库管理系统可以有效地组织和管理大量可复用构件, 并提供相应的工具支持开发者在软件开发过程中方便地查询、理解和选取构件, 使CBSD成为现实。

3.3 构件的复用

由于每个构件在编制时针对的是满足不同需求的, 并且是基于上下文的不同假设, 在应用到一个系统时构件常常必须被改写。构件必须被改写的前提是保证构件间的冲突最小。对构件内部结构的理解程度决定了对构件适应的不同方法。常用的方法包括:白盒法、黑盒法和灰盒法。白盒法允许用户可以通过修改构件的源码使构件能与其他构件相互作用, 该方法可以对构件的特性进行细致的控制, 但修改源码可能会导致维护和升级问题。黑盒法允许用户可以得到构件的二进制可执行形式, 构件没有提供扩展机制或可编程接口API。灰盒法不允许用户修改源代码, 但提供构件自身的扩展机制或可编程接口API。

通用基本构件层为底层, 是整个集成环境和运行环境都使用的构件, 通用性好, 粒度最小, 可广泛复用, 属于黑盒复用。领域共性构件完成系统主要功能, 但通用性不如前者, 大部分使用前须进行修改和测试, 复用方式属于白盒复用或灰盒复用。

软件构件模型是关于开发可复用软件构件和构件之间相互通信的一组标准的描述。通过复用已有的软构件, 使用构件对象模型的软件开发者可以像搭积木一样快速构造应用程序。目前, 国际上已经形成了许多构件模型, 这些模型的目标和作用各不相同, 其中部分模型属于参考模型 (例如3C模型) , 部分模型属于描述模型 (例如RESOLVE模型和REBOOT模型) , 还有一部分模型属于实现模型。近年来, 已形成三个主流技术, 分别是OMG的CORBA、SUN的EJB和微软的DCOM。这些实现模型将构件的接口和实现进行了有效的分离, 提供了构件交互的能力, 从而增加了复用的机会, 并适应了目前网络环境下大型软件系统的需要。国内许多学者在构件模型的研究方面也做了不少的工作, 取得了一定成绩, 其中较为突出的是北京大学杨芙清院士等人提出的“青鸟构件模型”。

4 结束语

CBSD是借鉴传统工业生产模式, 首先是分析消费者需求, 设计整体结构框架, 然后根据需要到构件库中选择能完成相应功能的构件, 最后修改连接构件组装应用系统。在这个过程中, 构件的获取、管理和复用是该方法实施过程中的重要内容和成功的关键。

摘要:软件复用被认为是解决"软件危机"可行的、现实的解决方案, 而构件技术是软件复用的核心技术, 改变了传统的软件开发模式。构件的获取、管理和复用则是其中的重要内容。

关键词:软件复用,构件,CBSD

参考文献

[1]童怡.浅谈软件复用技术[J].福建电脑, 2009 (9) :49.

[2]陈明.基于软件构件的软件开发技术[J].漳州职业技术学院学报, 2007, 9 (2) :4-7.

基于构件的软件工程 篇10

随着计算机技术的飞速发展,以及与之相适应的新技术的不断涌现, 各行各业对软件开发的速度和质量要求有了很大提高。传统的“手工作坊”式软件开发方式已不能满足现在的软件市场需求;同时, 市场中有大量的遗留软件系统存在,加之软件规模越来越大, 这些都引导人们又重新思考软件系统的复用问题。1999年2月美国总统 IT 顾问委员会的一份报告中将软件列为重点支持的项目之一,认为软件是信息时代社会的最重要的基础设施,但是现实中这个基础却相当脆弱和不可靠,原因是软件越来越普及并且越来越复杂,缺乏开发可靠安全的各种软件的合用技术,软件的生产能力远远满足不了飞速发展的实际需求。因此,该报告又强调了支持软件开发方法和构件技术的基础研究。那么,什么是软件开发的构件技术,为什么把它提得这么高,它究竟对软件的开发和应用有些什么作用,构件技术的突破对软件产业的发展会带来什么影响和机遇,它的突破点又是什么,所有的这些问题正是本文要讨论的内容。

1 软件构件技术

1.1 什么是构件(Component)

这同什么是对象一样, 是大家都理解而难以准确定义的问题, 在软件工业界出现的一些概念只勾画出了这个复杂概念的轮廓,并没有一个明确的定义。

杨芙清,王千祥等人将构件定义为:构件是可以被复用的软件实体 ,由构件规约与构件实现两部分组成. 其中 ,构件规约主要由构件模型进行描述。构架是一类特殊的构件,它刻画了组成系统的构件和构件之间相互作用的关系。[1]

王直杰,张钰等人则对构件有如下定义:构件又称元件, 是指可方便地插入到语言、工具、操作系统、网络软件系统中的一种独立可重用的二进制形式的代码和数据。[2]

贺秋芳则将构件定义为:构件是应用程序中功能独立、可以明确辨识的构成成分,具有规范的接口描述,可以提供给第三方进行组装。构件可以是被封装的对象类、类树、一些功能模块、软件框架、软件构架(或体系结构) 、文档、分析件、设计模式等。[7]

这些定义基本上反映了构件的特性。一般地,我们可以这样理解构件:

构件是可用来构成软件系统的即插即用(plug and play) 的软件成分, 是可以独立地制造、分发、销售、装配的二进制软件单元。它由以下三大要素构成:

1.1.1 接口( Interface)

接口告诉构件的用户该构件能完成什么功能。

1.1.2 实现( Implementation)

实现就是让该构件得以运作的代码。一个构件可以有多个实现, 如一个构件可以同时有处理XML 文件的实现和处理关系型数据库文件的实现。

1.1.3 部署(Deployment)

部署是构件的存在形式,一般即为二进制代码或可执行文件。

1.2 软件构件技术的应用与构件模型

当前,软件构件技术已经有了广泛的应用,例如面向对象的分布式软件开发[3]和基于Web的企业应用等等。与此同时,也有不少企业加入到软件构件革新的队伍当中,例如BEA, Microsoft, IBM 和 Sun公司。比较显著的应用实例有IBM公司的San Francisco 工程[4]。它提供了可复用的分布式对象架构和一个丰富的软件构件库。在国内,比较著名的则是青鸟构件模型。[5]

构件模型(Component Model)是对构件本质特征的抽象描述。构件模型规定了构件接口的结构以及构件与软件构架、构件与构件之间的交互机制。构件模型通常还提供创建和实现构件的指导原则。一个被所有构件生产者和构件复用者所接受的构件模型实际上起到了构件标准化的作用。目前国际上已经出现了许多构件模型,有学术界的抽象程度较高的3C模型,也有应用于工程实践的实现模型(标准) , 其中最有影响的是CORBA、COM /DCOM 和EJB,而国内最著名的就是青鸟构件模型。

CORBA是由对象管理联盟(OMG)提出的,其核心是对象请求中介(ORB),是分布式对象借以相互操作的中介通道。ORB的作用是将客户对象(Client)的请求发送给目标对象(在CORBA中称为对象实现Object Implementation),并将相应的回应返回至发出请求的客户对象。ORB的关键特征是客户与目标对象之间通信的透明性。

COM ( Component Object Model) 是微软公司1995年提出的构件标准。DCOM (Distribute Component Object Model)是微软为支持网络环境而对COM进行的扩充,它使得基于COM的构件能够在位于不同机器上的两个进程间协作,使得程序员可以不必编写网络代码去处理分布式构件跨网络交互所需要的通信。DCOM中主要使用ActiveX构件作为其对象。COM+ 是微软1999 年提出的,COM,DCOM、MTS的功能有机地统一在一起,形成了一个概念、功能强的构件应用体系结构。

JavaBeans构件实现标准由Sun公司在Java语言的基础上提出的,它是一种代码构件组合重用技术,是一个可移植的、平台独立的CBSE基础设施,它允许软件开发人员基于Java 语言,开发并重用代码构件Bean。EJB ( Enterprise Java Beans)是Java Beans的扩展,是一种面向企业应用、基于Java平台的服务器端标准构件体系结构,用于使用Java程序设计语言建立平台无关的、分布式对象及面向事务的业务应用系统。

1.3 何为软件构件化

在1.1和1.2中我们能了结了构件和当前软件构件技术的发展状况。那么,究竟什么是软件构件化那?在这里我们认为所谓的软件构件化,就是要让软件开发像机械制造工业一样,可以用各种标准和非标准的零件来进行组装,或者像建筑业一样,用各种建筑材料搭建成各式各样的建筑。软件的构件化和集成技术的目标是:软件可以由不同厂商提供的,用不同语言开发的,在不同硬件平台上实现的软件构件,方便地、动态地集成。这些构件要求能互操作,它们可以放在本地的计算机上,也可以分布式地放置在网上异构环境下的不同结点上。实现软件的构件化,这是软件业界多年来奋斗的目标,可以说已经经过了几代人的努力。

2 基于构件的软件开发过程

基于构件的软件开发过程与传统的软件开发有着很大的不同,其中最显著的一点就是它的开发过程不再是“算法+ 数据结构”,而是“构件的开发+基于体系结构的构件的组装”。

2.1 基于构件的软件开发的基本思想

构件技术是应用级别的集成技术,其基本思想是将应用软件分解成为一个个独立的单元, 将软件开发地过程转变成为类似于搭积木的搭建过程,通过组装不同的软件构件单元来实现软件的集成,按照构件技术的观点, 应用软件的开发就成为各种不同构件的集成过程.这一过程可用下图来表示。如图1所示。

2.2 基于构件的软件系统的开发方法

基于构件的软件系统的开发以构件为核心, 而且在需求分析阶段就可着手进行构件收集工作, 增加了开发的并行程度, 这从另一个方面提高了开发效率。它的开发大体可以包括两部分: 一是构件的开发, 二是应用程序的开发。传统的开发方法包括面向对象的技术是以很小粒度的“软件片”开始的, 而基于构件的软件系统的开发方法是面向重用的, 面向接口和面向连接的。如下图2所示。

2.3 基于构件的软件系统的生命周期

基于构件的软件开发方式不仅可以显著的降低软件开发的时间和开发成本,而且它的生命周期也与传统软件开发的生命周期有着巨大的差别。

由于基于构件的软件系统的开发是通过选择一系列的构件并将它们组合起来的过程,它的生命周期与传统的软件系统是完全不同的.基于构件的软件系统的生命周期可归纳为:

a、需求分析;

b、软件架构的选择, 构建,分析和评估;

c、构件的开发,选择和组装;

d、系统集成;

e、系统测试;

f、软件维护。

2.4 基于构件的软件开发的一般流程

2.4.1 需求分析(Requirement Analysis)

基于构件的软件开发过程的需求分析与传统的软件开发方法大体相同都是对对象领域内的共性特征、共性需求、共性结构以及可变特征、特有需求进行归纳和一致性描述,本阶段的工作不必也未必能面面俱到, 可以随着以后行为分析的进行而不断地调整、具体、优化。

2.4.2 构件的开发,选择与修改(Component Development, Selection, Certification)

构件是整个构架中基本的逻辑单元和数据处理单元。选取适合的已有构件以及将新开发的领域构件加入构件库是本阶段乃至整个基于构件的开发方法的关键,它集中体现了软件复用思想。

这一阶段的主要任务包括根据目标系统的需要修改构件,根据开发平台的需要对构件进行必要的改变以及对构件进行适当的升级以便取得更好的应用效果等等。这一阶段工作的核心就是对构件进行修改以求它能同其它构件兼容以及在特定的系统进行应用。这一阶段开始时需要系统的需求,构件的需求以及构件开发相关的文件。结束后能够得到复合系统要求的构件和与系统集成和系统维护相关的文件。

一般的,可以从Internet网上现有的构件库或商业性软件机构进行已有构件的挑选, 也可以从先前开发的各种应用系统中提取。当然, 现有构件的接口与系统的要求可能存在差距,但并不等于该构件就不能被复用, 可以利用构件的扩展性进行进一步的剪裁加工, 以符合系统的要求。而新开发的领域构件的入库工作可以由专门的构件库管理系统完成。

2.4.3 软件架构的设计(System Architecture Design)

为了保证基于构件的软件系统能够正常有效的进行运转,系统的架构设计是十分重要的。架构的设计是评估,选择和构建基于构件的软件系统架构的过程。系统架构设计的目标是综合用户的需求,确定系统的规范,选择合适的架构和确定系统的实施细节,例如实施平台,程序语言等等。

通过研究和企业的具体实践来看基于构件的软件系统的架构应当是分层模块结构。这一架构如下图3所示:

软件的架构包括两大部分,一是应用层,它是支持一个企业正常运营的应用系统。二是构件层,包括软件中的各个构件,也分为三个层次。第一层包括仅仅应用在特殊的企业或者应用领域的构件,第二层指横跨企业内部的中层构件,包括普通的软件和与其它应用实体的连接部分,第三层是指连接操作系统和其它相关硬件的基础性构件。

这一阶段结束后我们应当得出系统集成需要的系统规范书和系统测试以维护阶段的详细要求。

2.4.4 系统集成(System Integration)

在所有的构件都就绪后, 最后就是把这些构件按系统构架组装应用系统。组装过程完成构件的连接(Connection) 和约束(Constraint) 工作, 一般只需要编写些基本代码, 诸如构件间的互相调用等即可。其过程大体包括四个部分集成,测试,改变构件和重新集成(如果需要的话)。这一阶段结束后得到系统测试需要的系统雏形和系统维护阶段需要的系统文档等。

2.4.5 系统测试(System Testing)

系统测试是确定一个系统能否满足特定的需求以及发现并改正系统实施过程中漏洞的过程。系统测试的目标是根据系统需求选择的构件集成的最终系统。系统测试应当包括功能测试和稳定性测试。在这一阶段中需要选择合适的测试方法,包括单元测试(测试单个构件),集成测试(测试由构件构成的子系统),系统测试(测试由子系统构成的整个系统)等。需要的材料包括构件设计,开发,修改阶段以及系统集成阶段的文件。通过系统测试可以得到系统维护阶段需要的资料。

2.4.6 系统维护(System Maintenance)

系统维护是指对系统的日常维修,护理和改善。其目的是通过修改错误,改善软件的运行水平以及其它活动使系统能够适应复杂多变的活动,为用户提供一个更为有效的产品或者服务。一般而言,系统维护主要有三种类型:

纠正性维护(Corrective maintenance):用以改正现有系统的失误和缺陷。

完善性维护 (Improving maintenance):用以扩展现有系统的应有范围及提高其处理能力。

适应性维护(Adaptive maintenance):用以调整与改正系统的应用和功能,以使现有的信息系统可以更好地适应环境和管理需要的变化。随着行业竞争加剧和经营环境的多变,系统的适应性维护已越来越重要。

至此,一个基于构件的软件系统就完成了。当然本文只是简单的论述一般的思路和方法,具体每个步骤中用到的方法和编程的技巧性问题不属于本文阐述的对象,故而不再详细的赘述。

3 基于构件的软件工程的突破点

综合上面各个部分的论述,与传统的软件开发方式相比,基于构件的软件开发方法有什么突破呢?

3.1 体系结构

传统的应用系统体系结构从基于主机的集中式框架,到在网络的客户端上通过网络访问服务器的框架,都不能适应目前企业所处的商业环境, CBSE为开发这样的应用系统提供了新的系统体系结构。它是标准定义的、分布式、模块化结构,使应用系统可分成几个独立部分开发,可用增量方式开发。 CDSE从系统高层次的抽象上解决了复用性与异构互操作性,这正是分布式网络系统所希望解决的难题。

3.2 开发过程

传统的软件开发过程在重用元素、开发方法上都与CBSE有很大的不同。CBSE实现了分析、设计、类等多层次上的重用。在软件开发方法上,CBSE引导软件开发从应用系统开发转变为应用系统集成。建立一个应用系统需要重用很多已有的构件模块,这些构件模块可能是在不同的时间、由不同的人员开发的,并有各种不同的用途。在这种情况下,应用系统的开发过程就变成对构件接口、构件上下文以及框架环境一致性的逐渐探索过程。概括地说,传统的软件开发过程是串行瀑布式、流水线的过程;而CBSE是并发进化式,不断升级完善的过程。

3.3 软件方法学

传统的软件方法学是从面向机器、面向数据、面向过程、面向功能、面向数据流、面向对象等不断创新的观点反映问题的本质。CBSE发展到今天把应用业务和实现分离,即逻辑与数据的分离,提供标准接口和框架,使软件开发方法变成构件的组合。因此,软件方法学是以接口为中心,面向行为的设计。

3.4 构造方法

传统应用软件的构造是用白盒子方法,应用系统的实现全在代码中,应用逻辑和数据粘结在一起。而CBSD 的构造是用白盒子和黑盒子相结合的方法。 基于构件的框架是用两个概念来支持演变:第一个概念是构件有很强的性能接口,使构件逻辑功能和构件模型的实现都隐藏起来。这样,只要接口相同,构件就可以被替换。 第二个概念是隐式调用,即在基于构件的框架中,从来不直接给构件的接口分配地址,只在识别构件用户后才分配地址。因此,构件用户只要了解接口要求和为构件接口提供的引用后的返回信息。构件接口的信息并不存入构件内,而是存入构件仓库或注册处。这样才能保证构件替换灵活,并很容易利用隐式调用去重新部署构件。由于构件的实现对用户透明,因此也使构件能适应各种不同的个性化要求。

4 结束语

本文通过引入构件技术介绍了什么是软件构件技术以及其当前的应用现状,同时介绍了基于构件的软件开发的一般过程和软件构件技术的突破所在。基于构件的软件开发已经不是什么新名词,但是目前世界上还没有开发商用构件的公司出现,还没有形成规模化专业化、商品化的构件生产,可供使用的商品化业务构件还很少,同时基于构件的开发方法还有许多有待于进一步解决的问题,如系统构件、组织构件及构件库的规范和标准化问题,与人工智能、软件自动化技术的进一步的结合问题等等。但是我们可以相信,随着技术的不断发展,采用构件化和软件复用的方法进行软件开发必将受到人们越来越多的重视。

摘要:基于构件的软件工程(Component Based Software Engineering,以下简称CBSE)是提高软件产品质量与软件生产效率的关键技术。它是根据“选择合适的构件产品并按照完整的软件架构将它们组装起来”这一思想发展起来的。在此,重点论述与CBSE技术相关的系列问题:CBSE产生的背景,构件技术在软件开发中的作用及地位,基于构件技术的软件开发过程,以及CBSE与传统软件技术相比的突破点等。

关键词:CBSE构件,软件工程

参考文献

[1]杨芙清,王千祥等.基于复用的软件生产技术[J].中国科学:E辑2001年31卷4-363-371页.

[2]傅音翔,王直杰,张珏.一种基于构件的软件开发方法[J].微计算机信息2006年第22卷第1-3期228-230页.

[3]S.S.Yau,B.Xia.Object-Oriented Distributed Component Software Development based on CORBA.Proceedings of COMPSAC’98.The Twenty-Second Annual International,1998,pp.246-251.

[4]IBM:http://www4.ibm.com/software/ad/san-francisco,Mar,2000.

[5]青鸟构件模型http://www.sei.pku.edu.cn/jadebird/index.html.

[6]杨芙清,梅宏,李克勤.软件复用与软构件技术[J].电子学报,1999,27(2):68275.

[7]贺秋芳.基于构件的软件复用技术[J].广东轻工职业技术学院学报,2005年9月第4卷第3期.

基于构件的软件工程 篇11

关键词:钢筋混凝土框架;修正Park-Ang损伤模型;增量动力分析;易损性分析;柱拟静力试验

中图分类号:TU375 文献标识码:A

文章编号:1674-2974(2016)05-0009-13

Abstract:This paper study discussed the applicability of Park-Ang model modified by Wang based on the pseudo-static test results of reinforced concrete columns. The structural damage index based on the component level was selected, and both the incremental dynamic analysis and fragility analysis of the reinforced concrete frame were conducted. Additionally, the prediction by the modified method to evaluate the seismic performance in terms of the damage index of the RC frame was compared with the maximum inter-story drift ratio of the fragility analysis result. The analysis results show that the modified Park-Ang model that considers the loading path effect predicts well the cumulative damage process after the first damage, which discriminates the specimen damage status accurately, the damage development process, and the overall and local failure mechanism. Further, the weak links can be accurately distinguished. However, the damage index higher than 1.0 may be caused by using these methods, which cannot accurately reflect the basic meaning of the original definition. Compared with the maximum inter-story drift ratio, the seismic performance evaluation method using the damage index considers the structural response and properties. The modified method can be used to evaluate the structural performance more comprehensively and predict the failure probability of the structures under different earthquake loads.

Key words:reinforced concrete frame; fixed Park-Ang damage model; incremental dynamic analysis; fragility analysis; pseudo-static test of columns

基于构件的软件开发方法及实现 篇12

提高软件开发效率, 增强软件鲁棒性, 降低软件维护成本以及最大化软件的通用性和重用性, 一直是人们不懈追求的目标, 构件技术也因此应运而生。近年来, 构件技术不断发展, 出现了CORBA、COM/DCOM/COM+、Java Bean/EJB三大构件技术标准。与此同时, 为了更有效地将诸多构件组织成一个有机的系统, 减少系统的复杂性和提高系统的复用性, 基于构件的开发方法得到了广大研究开发人员的普遍关注并发展迅速。

1 构件的概念和标准

构件又称元件, 是指可方便地插入到语言、工具、操作系统、网络软件系统中的一种独立可重用的二进制形式的代码和数据, 它由以下3大要素构成:

(1) 接口 (Interface) 。接口告诉构件的用户该构件能完成些什么功能。

(2) 实现 (Implementation) 。实现就是让该构件得以运作的代码。一个构件可以有多个实现, 如一个构件可以同时有处理XML文件的实现和处理关系型数据库文件的实现。

(3) 部署 (Deployment) 。部署是构件的存在形式, 一般即为二进制代码或可执行文件。

同时, 一个构件之所以能成为构件, 它必须具有封装性、描述性、替换性、扩展性这4个重要属性。

(1) 封装性。封装是对构件实现和构件代码的一种隐藏。构件的使用者不必了解构件的具体实现, 只需通过构件的接口就能获得相应的功能。这样, 一旦构件内部实现需要调整, 将不会影响构件用户的使用。

(2) 描述性。由于构件的封装性, 要使用户能正确使用构件, 构件必须对自身进行描述, 以提供足够的使用信息给用户, 这些信息主要包括对构件的接口、实现和部署的描述。对接口的描述告知用户构件所提供的所有接口名及各接口所能完成的服务;对实现的描述告知用户构件是如何构造的, 如数据存储使用的是XML文件还是关系型数据库;对部署的描述则告知用户构件的运行环境, 如COM+、CORBA等。

(3) 替换性。构件的封装和描述属性使得构件具有可替换性。这是因为, 封装性保证了构件内部实现的调整不会影响到用户的正常使用, 而描述性则提供用户丰富的接口信息以供所需服务的调用, 也就是说, 只要有相同的接口, 一个构件完全可以由另一个构件替换, 哪怕它们的内部实现各不相同。

(4) 扩展性。简单地说, 扩展性就是指在不影响用户使用构件的情况下增加构件的功能。这种扩展可以藉由两种方法达成, 即:

(1) 增加接口。该方法多为构件开发者采用, 因为构件开发者可以直接对内部实现进行修改。同时, 考虑到兼容性, 构件的原有接口会得到保留, 而把新增的功能通过新添加的接口供用户调用。

(2) 授权 (Delegating Responsibility) 。该方法多为构件用户使用, 因为构件用户由于构件的封装性, 无法直接修改构件的内部实现。该方法将创建一个新的构件, 原构件无法提供的功能在此新构件中实现, 已提供功能则在此新构件中继续被调用。

图1是这两种扩展方法的示意图。

2 软件开发体系结构的实现问题

软件体系结构其设计的核心是能否使用重复的体系模式。传统的应用系统体系结构从基于主机的集中式框架, 到在网络的客户端上通过网络访问服务器的框架, 都不能适应目前企业所处的商业环境, 原因是:

(1) 企业过分地依赖于某个供应商的软件和硬件产品。这种单一供应商使得企业难以利用计算供应商的免费市场, 将计算基础设施的重要决定交给第三方处理, 这显然不利于企业在合作伙伴之间共享信息。

(2) 不能适应远程访问的分布式、多层次异构系统。封装的应用系统在出现某种组织需要时, 难以用定制来维护系统, 从而难以满足多变的需求。

(3) 不能实现分析、设计核心功能重用, 最多只能实现代码重用。

3 基于构件的开发模型

基于构件的开发模型利用模块化方法将整个系统模块化, 并在一定构件模型的支持下复用构件库中的一个或多个软件构件, 通过组合手段高效率、高质量地构造应用软件系统的过程。基于构件的开发模型融合了螺旋模型的许多特征, 本质上是演化形的, 开发过程是迭代的。基于构件的开发模型由软件的需求分析和定义、体系结构设计、构件库建立、应用软件构建, 以及测试和发布5个阶段组成, 采用这种开发模型的软件过程如图2所示。

构件作为重要的软件技术和工具得到极大的发展, 这些新技术和工具有Microsoft的DCOM、Sun的EJB, 以及OMG的CORBA等。基于构件的开发活动从标识候选构件开始, 通过搜查已有构件库, 确认所需要的构件是否已经存在。如果已经存在, 则从构件库中提取出来复用;否则采用面向对象方法开发它。之后利用提取出来的构件通过语法和语义检查后将这些构件通过胶合代码组装到一起实现系统, 这个过程是迭代的。

基于构件的开发过程就是构件组装的过程, 维护的过程是构件升级、替换和扩充的过程。其优点是构件组装模型导致了软件的复用, 提高了软件开发的效率。构件可由一方定义其规格说明, 被另一方实现。然后供给第三方使用, 构件组装模型允许多个项目同时开发, 降低了费用, 提高了可维护性, 可实现分步提交软件产品。

4 基于构件的开发方法的实现

在引入并行工程思想、领域工程思想及结合面向对象的建模机制, 一种实用的基于构件的开发模型如图3所示。

4.1 领域分析

领域分析对对象领域内的共性特征、共性需求、共性结构以及可变特征、特有需求进行归纳和一致性描述, 具体包括需求分析和详细设计等, 它将决定整个应用系统将完成哪种功能、支持哪些业务逻辑过程。由于引入迭代方法, 本阶段的工作不必也未必能面面俱到, 可以随着以后行为分析的进行而不断地调整、具体、优化。

4.2 行为分析

行为分析将确定应用系统的构架 (Architecture) 和具体要实现的功能。在领域分析的基础上, 本阶段将详细规划如何支持并实现这些需求。在引入面向对象的建模机制后, 这些工作可以藉由UML (Unfied Modeling Language, 统一建模语言) 中的用例图 (Use Case Diagram) 完成。经过领域分析和领域建模后, 领域知识已被按层次和结构分类组织, 概念结构也被转化为逻辑结构, 接下来的工作便是软件构架的确定。在软件系统中, 构架是可预制和可重构的软件骨架, 是问题域模型转化为解域模型的框架式系统。目前, 一般基于分布式体系的软件系统的构架大致可以分为用户界面层、事务逻辑处理层、数据处理层3大层。

领域建模和构架设计完成后, 整个应用系统的行为即得到确定, 进而可以对所有这些行为进行构件粒度上的划分。

4.3 构件和互操作 (Interaction) 的确定

构件是整个构架中基本的逻辑单元和数据处理单元, 依据先前的领域分析和领域建模, 可以按需进行大至类库、类, 小到函数、结构等不同粒度构件的划分, 并从模型、模板等不同角度进行构件的设计和生成。

在构件与构件、构件与用户的互操作过程中, 接口其实代替了构件的角色, 且随着接口的确定, 互操作也将得以确定, 因此接口的设计在构件的设计中至关重要, 它必须具有高度的内聚性, 即接口应该有明确的应用目的及相应的功能。一个标准的接口, 既要能清晰表达所要完成的功能, 也要具备良好的互操作性。我们常会犯的一个错误就是一个接口所表达的功能太繁杂, 从而导致接口过于庞大, 往往一个接口容纳了多个接口的功能。

在接口设计的同时, 应做好相关描述信息的文档化工作, 这些信息包括该接口的输入信息、输出信息、调用前状态、调用后状态和备注等。

4.4 构件组装和构件复用

确定了构件的接口和互操作后, 随之进行的就是整个应用系统的开发工作, 包括构件的开发、已有构件的剪裁、软件流程的衔接、构件的组装等。同时, 选取适合的已有构件以及将新开发的领域构件加入构件库是本阶段乃至整个基于构件的开发方法的关键, 它集中体现了软件复用思想。我们一般可以从Internet网上现有的构件库或商业性软件机构进行已有构件的挑选, 也可以从先前开发的各种应用系统中提取。当然, 现有构件的接口与系统的要求可能存在差距, 但并不等于该构件就不能被复用, 可以利用构件的扩展性进行进一步的剪裁加工, 以符合系统的要求。而新开发的领域构件的入库工作可以由专门的构件库管理系统完成。

在所有的构件都就绪后, 最后就是把这些构件按系统构架组装成应用系统。组装过程完成构件的连接 (Connection) 和约束 (Constraint) 工作, 一般只需要编写些基本代码, 诸如构件间的互相调用等即可。

5 结束语

如今, 随着Internet的广泛普及和电子商务的迅速成长, 分布式应用越来越多地得到各企业的采用, 而基于构件的开发方法正是一种适合企业级分布式应用的灵活、高效的开发方法, 它能轻松应对企业不断变化的商务需求, 而且能进一步降低开发、维护费用。当然, 基于构件的开发方法并不是万能的, 还需要在更多应用系统的开发中检验和改进。

参考文献

[1][美]布朗.大规模基于构件的软件开发[M].赵文耘, 译.北京:机械工业出版社, 2003.

[2]蔡明, 陈永运.J2EE架构的研究与应用[J].计算机应用与软件, 2004 (1) .

[3]蔡伟纲.NIOS (Ⅱ) 软件架构解析[M].西安:西安电子科技大学出版社, 2007.

[4]谢晓芹, 陈凯云.基于构件的叶片型面测量软件设计与实现[J].计算机工程与应用, 2004 (20) .

[5]徐建民.软构件技术在信息系统开发中的应用研究[J].微机发展, 2003 (3) .

[6]杨芙清, 梅宏主, 黄罡, 等.构件化软件设计与实现[M].北京:清华大学出版社, 2008.

[7]张友生, 等.软件体系结构[M].北京:清华大学出版社, 2006.

上一篇:诗词十一首下一篇:高校聋哑学生体育教学