软件构件与中间件

软件的本质特性:

构造性,演化性,知识密集,逻辑产物。

软件开发模型:瀑布模型,螺旋模型,喷泉模型,演化模型

瀑布模型:文档驱动。系统可能不满足客户的需求

螺旋模型:风险驱动。风险分析人员需要有经验。且经过充分训练

喷泉模型:更多的增量和迭代

演化模型:需求驱动。需求分组会影响全局系统

软件危机:现象:软件开发费用和进度失控,软件的可靠性差,软件难以维护。

原因:需求不明确,缺少有力的技术、方法学和工具,复杂程度越来越高,人的原因

软件开发呈现的变化:

反映对象:从 以个体计算过程 为反映对象向 以群体合作过程 为反映对象的发展

开发基础:从 以单个软件开发为主  以集成式开发为主 的发展

关注内容:从 以正面功能为核心  向兼顾侧面约束 的发展

运行方式:从 纯被动式的方式 向 部分主动式的方式 发展

提交形式:从 以 产品 为中心向 以 服务 为中心 的发展

开销比重:从 开发为主要开销开发、演化开销并重 的发展

面向方面的编程(AOP):追求 调用者和被调用者之间的解耦

代理的特征:自治性,反应性,主动性,社会性

什么是工作流:工作流是一类能够完全或者部分自动执行的业务过程,本质上讲是

使在多个参与者之间按照某种预定义的规则传递文档、信息或任务

的过程自动进行。

软件开发过程新进展:(1) 统一软件开发过程(RUP)

生命周期的四个阶段:初始阶段,细化阶段,构造阶段,交付阶段

(2) 敏捷开发方法

Agile software development is a groupof software development methodologies based on

iterative and incremental development,where requirements and solutions evolve through

collaboration between self-organizing, cross functional teams.

(3) 面向侧面的软件开发(AOP)

(4) 测试驱动的软件开发

在开发功能代码之前,先编写测试代码。也就是说在明确要开发某个功能后,首先思考如何对这个功能进行测试,并完成测试代码的编写,然后编写相关的代码满足这些测试用例。然后循环进行添加其他功能,直到完全部功能的开发。

(5) 基于构件的软件开发

构件的定义:一个构件是一个组装单元,它具有约定式规范的接口以及明确的依赖环境,构件可以被独立地部署,由第三方组装

软件构件则是软件系统中 具有一定意义的相对独立的构成成分。软件构件主要是指可复用软件构件。

构件是可以被复用的软件构成成分,由构件规约构件实现两部分组成

构件的信息,包含:提供给客户程序的信息,提供给构件运行环境的信息,

提供给构件库管理系统的静态管理信息

构件模型:是对构件本质特征的抽象描述,是实现系统化复用的关键因素

1>描述模型:即分类模型。以综合的方式描述构件,便于构件的管理

REBOOT模型 :基于面向对象技术的复用。基于已有构件的一种刻面分类和检索模型

常见刻面:抽象,操作,操作对象,依赖

ALOAF模型 基于ALOAF的三层数据模型,元模型层,数据模型层,数据层

UDM、BIDM模型等UDM提供标准的软件构件描述数据模型

2>规约模型:

以描述构件的功能(行为)为主要目标

3C模型RESOLVE模型JBCOM模型等

3>实现模型:

以如何具体实现构件为主要目标,与分布式对象技术充分结合。

软件复用的两种方法

产品复用:复用已有的软件构件,通过集成(组装) 构件得到新系统

是 目前现实的、主流的途径。

产品复用的形式:黑盒复用:不需对构件作任何修改即可直接复用,这是理想的复用方式.

白盒复用:已有构件并不能完全符合用户需求需要根据用户需求进行适应性修改

过程复用:复用已有的软件开发过程,使用可复用的应用生成器来自动或半自动生成系统

依赖于 软件自动化技术的发展,目前只适用于一些特殊应用领域

成功复用的特点:

1,将复用范围缩小在一个特定领域2,有一个良好的系统框架对应用系统进行支持

3,构件接口明确4,对开发的影响:提高了程序员的产量,降低面市时间,影响系统的质量属性,为复用经济提供了基础

提取软件的共性成分,屏蔽系统较低层的复杂度,从而在高层保持复杂度的相对稳定。

网络环境的特点:分布性,演化行,复杂性,异构性,增长性

中间件是一种独立的系统软件或服务程序,中间件位于客户机服务器的操作系统之上,中间件是一类软件,而非一种软件

中间件类型:

终端仿真/屏幕转换:实现客户机图形用户接口与 已有的字符接口方式的服务器应用程序的互操作。

数据访问:建立数据应用资源互操作的模式

远程过程调用:方便程序员编写客户端应用程序,调用位于远端服务器上的过程

面向消息中间件:屏蔽各种平台及协议之间的特性,进行相互通信,实现应用程序之间的协同

事务(交易)中间件:在分布、异构环境下,提供保证交易完整性和数据完整性的一种环境平台。

对象中间件:在分布、异构的网络计算环境中将各种分布对象有机地结合在一起,完成系统的快速集成,实现对象重用

应用服务器以公共服务的方式实现了多数中间件的功能

ORB操作由ORB核心实现,不依赖于所用的对象适配器

OMA评价:只是一个体系结构模型,充分吸收众多的先进技术,发布周期长,形成效率低

CORBA的缺点:1,不同的CORBA实现之间会出现缺乏互操作性的现象。2,由于供应商常常会自行定义扩展,而CORBA又缺乏针对多线程环境的规范,对于像C或C++这样的语言,源码兼容性并未完全实现。3,CORBA过于复杂

DNA评价:1,既是指定者,又是实施者2,产品的集成性好,运行效率高3,对现有系统的依赖过多,不利于学习研究

J2EE评价:1,鼓励其他公司参与,最终决策在SUN2,提供参考实现,鼓励其他公司实现规范3,开发自己的服务器产品

TCP:1,TCP 为两个分布式的构件提供了双向的消息通信:2,它是一个可靠但较慢的协议

3,在客户服务器双方进行缓冲以提高速度

UDP:作用:将网络数据流量压缩成数据报的形式.构成:报头8字节+数据内容=数据报特点:不可靠但快速的协议

套接字是TCP/IP在因特网上的主要实现方式

套接字主要信息:TCP层:端口,IP层:IP地址

套接字的出现 促进了软件从单机环境向网络环境的发展.基于套接字的开发方式较为繁琐,软件排错十分困难

软件互操作:是网络环境中应用层的某一实体使用另一实体所提供功能。

RPC利用指代(Stubs)来完成客户与服务器的关联。

指代的作用:1将参数转化为易于识别的外部数据形式;2对参数进行编排;

3将参数与进程标识符打包成请求。4发送信息等待应答

RPC过程描述1)客户按本地调用的方式直接调用本地的客户指代2)客户指代将客户的调用请求进行加工、打包

向底层通信机制(如套接字)发出请求消息3)客户端通过底层的通信机制将消息传送给服务器端的底层通信机制

4)服务器需要部分地解析消息找出客户希望调用的服务器程序

将客户的高层调用语句打包为一条底层的请求消息这一过程在RPC中被称为编排(marshal)

将来自服务器底层的应答消息解析为可以返回的数据这一过程在RPC中被称为还原(unmarshal)

“指代” 目前主要被用于专门代表客户端的代理程序而服务器端则由新的机制予以支持。在CORBA中专门分离出了对象适配器在EJB中发展出了构件容器。

互操作体系:为支持应用层的某一实体使用另一实体而制定的一套技术规范

底层协议解决的问题:流量控制、路由选择、差错控制等

互操作协议解决的问题:字节序、数据表示等问题的解决方法体现了通信双方之间关于消息的数据格式消息的类型 等的约定

互操作接口定义语言IDL是用于对接口进行定义的语言

互操作查找方式主要是指服务器的定位

数据表示是一种传输语法,描述各种数据类型在传输线路上以比特流形式表示出来的格式

底层协议 主要解决通信的 可行性以及部分 可靠性 等问题

高层协议不同于底层协议的一个明显特征在于高层协议带有一定的语义信息

服务体引用以字符串的形式发布

CDR(Common Data Representation)是传输语法它将用OMG IDL定义的数据类型映射到低层表示CDR特点:可变字节序,对齐的主数据,完整的IDL映射

GIOP消息特点:消息简单,动态对象定位,完全的CORBA支持,GIOP支持传送特定于服务的环境  互操作对象引用(IOR)是IIOP的一个有机组成部分

IOR是一个数据结构,用于表示与对象互操作相关的信息。

IDL概述:在客户代码与对象实现(服务)之间定义了一个清晰的边界,IDL文件类似于应用程序接口(API)文档  IDL独立性:IDL是独立于平台的,独立于编程语言

COM,构件对象模型,目的:使应用程序更易于定制,更灵活.

COM标准包括规范实现两部分.

规范部分:1,定义了构件与客户之间进行交互所必须遵守的标准2,这些规范不依赖于任何特定的语言和操作系统

实现部分:1,COM支持库(而不是具体构件的实现)2,为COM规范的具体实现提供一些核心服务

COM构件提供给客户的是以对象形式封装起来的实体.全局惟一标识符GUID作为系统实体的标识

COM构件 DLLEXE形式发布的代码

DLL:进程内构件,运行时刻动态装载,同一进程空间.EXE:进程外构件,不同进程空间

接口是COM规约中的核心内容,是COM中的基础实体

EJB构件容器:加载EJB构件,记录上下文, 控制生命周期,控制对实例的访问

构件容器:目标:控制、管理系统资源,提高资源利用率

措施:1,实例池共享技术,将暂时不用的资源实例缓存起来,放到实例池中,当下一个客户需要访问资源时直接从实例池中取出来为客户服务2冻化/激活。有态构件不同于无态构件的地方在于:有态构件保持一个业务过程中前后方法调用之间的状态

3生命周期管理:构件的生命周期管理主要是指构件实例的生命周期管理

为什么需要CMP:BMP构件代码中与数据库相关的代码多;BMP对特定数据存储系统的依赖性太大

EJB的优点:1,在中型至大型系统中,应用EJB可以提高系统的访问速度及访问用户数量2,EJB可以方便程序员的逻辑事务处理3,EJB可以方便系统升级:直接在服务器端升级EJB,而不需要更新客户端代码EJB的缺点:1,EJB需要安装中间层服务,增加了计算机内存的占用。单机系统中,JavaBean就可以实现EJB的功能

2,访问EJB首先要连接中间层服务器,增加了访问时间,所以在小型应用中,单机结构和二层结构的系统更为快捷。

webService:自描述、自包含软件模块,通过网络使用,拓扑结构

WEB服务的特性:Web服务是自包含的,是自描述的,是独立于实现技术和可互操作的,是开放的,基于标准的.是松耦合的

Web服务提供编程的访问能力,Web服务提供打包现有应用程序的能力,通过实现Web服务作为接口,可方便的把现有独立应用程序集成到SOA中。

SOAP:简单对象访问协议是网络环境中交换信息的简单协议,为网络环境下软件之间结构化类型化信息的交换提供了一种基于XML的机制.它可以广泛地用于基于消息的系统和基于RPC的系统SOAP.

SOAP以HTTP作为底层通讯协议;以RPC作为一致性的调用途径;以XML作为数据传送的

协议比较:1互操作开销不同,2,表达能力不同,3适应能力不同,4适用环境不同

公共服务的基本概念:软件公共服务则可以看作主要是分层、分治原则的的运用

公共服务的定义:公共服务是应用服务器的组成部分,用于对应用的约束性需求进行支持 

公共服务与构件容器都为软件构件提供必要的支持,但的支持方式与内容都有所不同。

从支持方式看:构件所需要的服务是由构件容器直接支持的;公共服务的支持通常是通过构件容器进行的

从支持内容看:容器主要支持那些不需要额外资源的约束;公共服务主要支持那些需要额外资源的约束

公共服务的使用方式:1代码 调用式使用方式2后期声明式的使用,应用程序代码不直接调用公共服务,而是由容器(截取器)进行调用

公共服务的实现:(1)可以在应用服务器内实现(2)可以由另外一个单独的中间件产品实现(3)可以在局域网内的另一个应用服务器实现(4)可以作为一种网络基础设施

cos设计原则:建立在CORBA规范之上;服务是基本的、灵活的(简单、专注);服务具有一般性;COS也是一种CORBA对象;服务质量(QoS)是实现特征;一个服务通常包含多个对象;使用回调接口

J2EE中的公共服务接口:查找服务接口JNDI;事务服务接口JTA;安全服务接口;消息服务接口JMS;邮件服务接口;资源访问服务接口

名字的分类:原子名字,名字中不可分割的部分;复合名字,包含了零个或多个原子名字的一个序列;合成名字,是跨越多个命名系统的名字, 包含了一个有序的复合或原子名字的列表,每个复合或原子名字属于不同的命名系统名字空间

应用层-名字:名字是便于阅读的字符串,需要注册,同一名字空间中不允许重名,不同名字空间中的实体允许重名,一个实体允许多个名字;系统层-标识,一串数字组成的特定编号,实体与实体标识一一对应;客户域-引用,客户定位构件所用的信息可以是指代,也可以是存储在名字服务器中的一条记录包括:访问协议、IP地址、端口、标识等

合约服务:是增强的目录服务 可以在不断变化的网络环境中提供定位服务的功能;目前只有Web服务的UDDI提供合约服务;UDDI最核心的部分是一个基于仓库池的目录服务-商业注册库

系统组装特性:1)依赖于构件模型2)组装者仅需要了解构件的规约(不必掌握构件的实现)

3)需要考虑公共服务应用系统组装是在构件与构件之间以及构件与公共服务之间建立起有效的关联从而构成满足用户需求的应用系统的过程。

技术领域:构件的形态划分,构件之间的关联方式划分,构件与公共服务之间的关联方式划分

1)根据构件的形态划分:基于源代码形态构件的组装,该类组装在源代码编写阶段或者源代码编译阶段完成2)基于存储态目标码形态构件的组装,该类组装在系统链接等阶段完成3)基于运行态构件的组装,所需要的构件已经处于运行状态

领域工程 是获取构件的主要途径,目的:对特定领域中可复用成分的分析、生产和管理

什么是领域/strong>一组具有相似或相近软件需求的应用系统所覆盖的功能区域

领域的划分:垂直领域:即行业领域。把特定行业内的软件应用覆盖的功能区域视为软件领域.水平领域:不同行业之间存在的相同的软件功能区域

软件包含三种构成成分:通用共性成分,领域共性成分,应用特定成分

领域工程方法:FODA面向特征的领域分析方法;DSSA特定领域软件构架方法;FAST;青鸟

FODA:1,上下文分析:确定被分析领域的范围,建立上下文模型,包括结构图、数据流图2,领域建模,特征模型,实体关系模型,功能模型。完成三种模型的建立和验证3,体系结构建模,应用系统的高层设计,关注共性模块和进程

FORM领域工程方法:从 服务、操作环境、领域技术、以及实现技术 四个方面分析共性差异性产生特征模型

三个不同的视图:子系统:封装了特征模型中的服务特征。进程模型:封装了特征模型中操作特征和其他一些非功能属性特征。模块模型:封装了特征模型中的领域特征技术和实现特征

DSSA:以体系结构为中心的领域工程方法,通过为目标领域建立一个通用的参考体系结构来实施软件复用

建立领域分析模型有三个活动:建立领域需求定义建立领域面向对象分析模型建立领域术语字典

系统分析:根据领域工程获得的领域分析模型对照用户需求确认领域分析模型中的变化性需求或提出的新需求,以获得具体的新系统分析模型。其过程包括: 确定具体的业务模型,固定领域分析模型中的变化性,调整领域需求模型 最终用户的持续参与是获得良好模型的重要因素

系统设计的目标在于:以领域工程获得的DSSA为基础对照具体系统的分析模型获取具体的系统设计模型其核心环节是根据系统的需求模型固定DSSA中相关的变化成分如果对领域的知识有所增加 则需要对DSSA进行一定的调整。

系统实现的目标为:以领域构架/构件为基础对照具体系统的设计模型将构件与构架进行集成组装并进行必要的代码编写工作以实现并测试最终的应用系统。

 

来源:ThanksCreek

声明:本站部分文章及图片转载于互联网,内容版权归原作者所有,如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢!

上一篇 2013年5月3日
下一篇 2013年5月3日

相关推荐