CMMI之功能点估算法---内部逻辑文件和外部接口文件
2008-01-24 作者：张瑾
关键词：CMMI、软件工程、MA、度量、PP、项目计划、项目估算
功能点估算法是软件项目管理众多知识中比较有技术含量的一个。在软件项目管理中项目计划制定的优劣直接关系到项目的成败，项目计划中对项目范围的估算又尤为重要，如果项目负责人对项目的规模没有一个比较客观的认识，没有对工作量、所需资源、完工时间等因素进行估算，那么项目计划也就没有存在的意义。
FP功能点估算法的特点
项目范围的估算在CMMI的“MA”度量分析管理和“PP”项目计划中均有涉及，对软件项目范围的估算有很多种方法，常见的就是LOC代码行和FP功能点法，它们之间的区别和关系如下：
1.FP功能点估算法常用在项目开始或项目需求基本明确时使用，这时进行估算其结果的
准确性比较高，假如这个时候使用LOC代码行估算法，则误差会比较大。
2.使用FP功能点估算法无需懂得软件使用何种开发技术。LOC代码行估算法与软件开
发技术密切相关。
3.FP功能点法是以用户为角度进行估算，LOC代码行估算法则是以技术为角度进行估
算的。
4.通过一些行业标准或企业自身度量的分析，FP功能点估算法是可以转换为LOC代码
行的。
在项目刚开始的时候进行功能点估算可以对项目的范围进行预测，在项目开发的过程中由于需求的变更和细化可能会导致项目范围的蔓延，计算出来的结果会与当初估计的不同，因此在项目结束时还需要对项目的范围情况进行估算，这个时候估算的结果才能最准确反映项目的规模。
功能点分析的步骤
在本文中将以国际标准IFPUG（International Function Point Users Group）组织提供的功能点估算法V4.1.1为基础与大家进行讲解。如下图所示，首先大家应该了解功能点估算法的使用步骤。
图功能点估算的步骤
1.识别功能点的类型。
2.识别待估算应用程序的边界和范围。
3.计算数据类型功能点所提供的未调整的功能点数量。
4.计算人机交互功能所提供的未调整的功能点数量。
5.确定调整因子。
6.计算调整后的功能点数量。
识别项目的类型
国际的IFPUG组织将软件项目分为三类，功能点估算法适用于任何一类项目?新开发项目
?二次开发的项目
?功能增强的项目
识别项目的范围和边界
使用UML的“UseCase”用例图是以用户角度进行识别项目范围和边界的最好方法，因为在画用例图时就必须明确系统的边界。通过系统的边界我们可以知道哪些功能要计算功能点，哪些功能点是外部系统负责计算的。以下图为例：一个外贸订单系统只包含录入、修改、删除、查询和统计订单的功能，而汇率查询转换服务是不属于该系统的。
应用程序边界的识别规则大家一定要牢记，不能从技术角度去思考，必须从用户角度来定义；如果项目牵扯到多个系统，那么必须将这多个系统的边界全部描述清楚。
图外贸订单系统用例图
FP功能点估算分类
FP功能点估算法将功能点分为以下5类：
1.ILF：Internal Logical File内部逻辑文件
2.EIF: External Interface File外部接口文件
3.EI: External Input外部输入
4.EO: External Output外部输出
5.EQ: External Inquiry外部查询
其中ILF和EIF属于数据类型的功能点，EI、EO、EQ属于人机交互类型的功能点。以外贸订单系统项目为例：
?录入订单、修改订单、删除订单是EI；
?查询订单是EO
?统计订单是EQ
?汇率查询转换系统为EIF
?订单和客户是ILF
识别功能点的重要原则
ILF、EIF要与EI、EO、EQ分开计算。对ILF和EIF复杂度的计算可以简单理解为对数据库复杂度的计算。对EI、EO、EQ复杂度的计算可以理解为对程序开发复杂度的计算。一般软件项目都是由数据和程序构成的，因此计算ILF、EIF和计算EI、EO、EQ之间没有任何关系。
内部逻辑文件与外部接口文件
ILF内部逻辑文件
内部逻辑文件是指一组以用户角度识别的，在应用程序边界内且被维护的逻辑相关数据或控制信息。ILF的主要目的是通过应用程序的一个或多个基本处理过程来维护数据。
EIF外部接口文件
外部接口文件是指一组在应用程序边界内被查询，但它是在其他应用程序中被维护的，以用户角度来识别的，逻辑上相关的数据。因此一个应用程序中的EIF必然是其他应用程序中的ILF。EIF的主要目的是为边界内的应用程序提供一个或多个通过基础操作过程来引用的一组数据或信息。
EIF所遵循的规则：
?从用户角度出发识别的一组逻辑数据。
?这组数据是在应用程序外部，并被应用程序引用的。
?计算功能点的这个应用程序并不维护该EIF
?这组数据是作为另一个应用程序中的ILF被维护的。
ILF和EIF复杂性计算
ILF和EIF的复杂性是取决于RET（Record element type）和DET（Data element type）的数量。DET是一个以用户角度识别的，非重复的有业务逻辑意义的字段。
DET计算的规则如下：
?通过一个基本处理过程的执行，对ILF进行维护或从ILF/EIF中返回一个特定的、用户可识别的、非重复的字段，那么每个这样的字段算一个DET。
o例如：添加一个外贸订单时需要保存“订单号码、订单日期、地址、邮编”，那么对于ILF订单来说它的DET就是4个。
o例如：保存订单时还会保存订单的明细，订单的明细往往作为一个子表进行保存，那么“订单号码”在主表和子表中都同时存在（主外键），但以用户角度来
识别时，存盘操作是一个最小的单位，那么订单号码只能算做一个DET。
?当两个应用程序维护和/或引用相同的ILF/EIF，但是每个应用程序分别维护/引用它们相应的DET时，这些DET在这两个应用程序的维护或引用中将单独计算。
o例如一个应用程序的两个“Elementary Process”基本处理过程都需要使用到“地址”的信息，地址的信息又可以细分为“国家、城市、街道、邮编”。那么对
于其中一个基本处理过程来说，他将整个地址信息作为一个整体进行处理，那
就只算一个DET，另外一个基本处理过程使用每个地址的详细信息，那么DET
就是4个。
RET计算的规则如下：
RET是指一个EIF/ILF中用户可以识别的DET的集合。如果把DET简单理解为字段的话，那RET就可以简单理解为数据库中的表。RET在ILF/EIF中分为两种类型：可选的（Optional）和必选的（Mandatory）。计算RET的规则为以下两点：
?在一个ILF/EIF中每一个可选或必选的集合都被计算为一个RET。
?如果一个ILF/EIF没有子集合，则ILF/EIF被计算为一个RET。
例如：在外贸订单系统中添加一个订单时会保存“订单信息、客户的ID、部门的ID”。
那么订单系统ILF中RET为：
1、订单信息（必选的）
2、客户信息（必选的）
3、部门信息（可选的）
因此ILF中RET的个数为3个。
ILF/EIF复杂度的矩阵如下
系统对接设计 1.1.1对接式 系统与外部系统的对接式以web service式进行。 系统接口标准： 本系统采用SOA体系架构，通过服务总线技术实现数据交换以及实现各业务子系统间、外部业务系统之间的信息共享和集成，因此SOA体系标准就是我们采用的接口核心标准。主要包括： 服务目录标准：服务目录API接口格式参考以及关于服务目录的元数据指导规，对于W3C UDDI v2 API结构规，采取UDDI v2的API的模型，定义UDDI的查询和发布服务接口，定制基于Java和SOAP的访问接口。除了基于SOAP1.2的Web Service 接口式，对于基于消息的接口采用JMS或者MQ的式。 交换标准：基于服务的交换，采用HTTP/HTTPS作为传输协议，而其消息体存放基于SOAP1.2协议的SOAP消息格式。SOAP的消息体包括服务数据以及服务操作，服务数据和服务操作采用WSDL进行描述。 Web服务标准：用WSDL描述业务服务，将WSDL发布到UDDI用以设计/创建服务，SOAP/HTTP服务遵循WS-I Basic Profile 1.0，利用J2EE Session EJBs实现新的业务服务，根据需求提供SOAP/HTTP or JMS and RMI/IIOP接口。 业务流程标准：使用没有扩展的标准的BPEL4WS，对于业务流程以SOAP服务形式进行访问，业务流程之间的调用通过SOAP。 数据交换安全：与外部系统对接需考虑外部访问的安全性，通过IP白、SSL认证等式保证集成互访的合法性与安全性。 数据交换标准：制定适合双系统统一的数据交换数据标准，支持对增量的数据自动进行数据同步，避免人工重复录入的工作。 1.1.2接口规性设计 系统平台中的接口众多，依赖关系复杂，通过接口交换的数据与接口调用必须遵循统一的接口模型进行设计。接口模型除了遵循工程统一的数据标准和接口规标准，实现接口
系统对接设计 1.1.1对接方式 系统与外部系统的对接方式以web service方式进行。 系统接口标准： 本系统采用SOA体系架构，通过服务总线技术实现数据交换以及实现各业务子系统间、外部业务系统之间的信息共享和集成，因此SOA体系标准就是我们采用的接口核心标准。主要包括： 服务目录标准：服务目录API接口格式参考国家以及关于服务目录的元数据指导规范，对于W3C UDDI v2 API结构规范，采取UDDI v2的API的模型，定义UDDI的查询和发布服务接口，定制基于Java和SOAP的访问接口。除了基于SOAP1.2的Web Service 接口方式，对于基于消息的接口采用JMS或者MQ的方式。 交换标准：基于服务的交换，采用HTTP/HTTPS作为传输协议，而其消息体存放基于SOAP1.2协议的SOAP消息格式。SOAP的消息体包括服务数据以及服务操作，服务数据和服务操作采用WSDL进行描述。 Web服务标准：用WSDL描述业务服务，将WSDL发布到UDDI用以设计/创建服务，SOAP/HTTP服务遵循WS-I Basic Profile 1.0，利用J2EE Session EJBs实现新的业务服务，根据需求提供SOAP/HTTP or JMS and RMI/IIOP接口。 业务流程标准：使用没有扩展的标准的BPEL4WS，对于业务流程以SOAP服务形式进行访问，业务流程之间的调用通过SOAP。 数据交换安全：与外部系统对接需考虑外部访问的安全性，通过IP白名单、SSL 认证等方式保证集成互访的合法性与安全性。 数据交换标准：制定适合双方系统统一的数据交换数据标准，支持对增量的数据自动进行数据同步，避免人工重复录入的工作。 1.1.2接口规范性设计 系统平台中的接口众多，依赖关系复杂，通过接口交换的数据与接口调用必须遵循统一的接口模型进行设计。接口模型除了遵循工程统一的数据标准和接口规范标准，实现接
系统对接设计 1.1.1 3.7.3 对接方式 系统与外部系统的对接方式以web service方式进行。 系统接口标准： 本系统采用SOA体系架构，通过服务总线技术实现数据交换以及实现各业务子系统间、 外部业务系统之间的信息共享和集成，因此SOA体系标准就是我们采用的接口核心标准。主要包括： 服务目录标准：服务目录API接口格式参考国家以及关于服务目录的元数据指导规范， 对于W3C UDDI v2 API结构规范，采取UDDI v2 的API的模型，定义UDDI的查询和发布服务接口，定制基于Java和SOAP的访问接口。除了基于SOAP1.2的Web Service接口方式，对于基于消息的接口采用JMS或者MQ的方式。 交换标准：基于服务的交换，采用HTTP/HTTPS作为传输协议，而其消息体存放基于 SOAP1.2协议的SOAP消息格式。SOAP的消息体包括服务数据以及服务操作，服务数据和服务操作采用WSDL进行描述。 Web服务标准：用WSDL描述业务服务，将WSDL发布到UDDI用以设计/创建服务，SOAP/HTTP服务遵循WS-I Basic Profile 1.0，利用J2EE Session EJBs 实现新的业务服务，根据需求提供SOAP/HTTP or JMS and RMI/IIOP接口。 业务流程标准：使用没有扩展的标准的BPEL4WS，对于业务流程以SOAP服务形式进行访问，业务流程之间的调用通过SOAP。 数据交换安全：与外部系统对接需考虑外部访问的安全性，通过IP白名单、SSL认证等方式保证集成互访的合法性与安全性。 数据交换标准：制定适合双方系统统一的数据交换数据标准，支持对增量的数据自动进行数据同步，避免人工重复录入的工作。 1.1.2 3.3.8接口规范性设计 系统平台中的接口众多，依赖关系复杂，通过接口交换的数据与接口调用必须遵循统一的接口模型进行设计。接口模型除了遵循工程统一的数据标准和接口
1系统接口设计 1.1接口设计原则 接口设计总体上遵循高内聚、低耦合、精分解的设计原则，尽量减少各系统间、系统内各模块间的耦合度、降低操作复杂度、保证实现的通用性、提高系统的重用性和扩展性，具体原则如下： 主要原则 （1）所有的接口设计需遵循ITSS标准及行业接口规范； （2）技术上采用SOA组件化设计思想，实现系统间的松耦合。 其他原则 （1）使用简单、快捷，通用性好，可靠性高； （2）充分考虑接口所涉及系统的应用扩展，灵活支撑需求变化； （3）保证接口数据在接口所涉及的各个系统间的一致性； （4）在数据交互过程中，应具有传送和接收后的确认过程； （5）以XML格式数据为主要的数据传输载体。 1.2接口定义与分类 1.2.1内部接口 内部接口主要是指各个子系统间的接口关系，主要包含数据接口和服务调动接口。 1、内部系统间数据接口 主要是各子系统间数据共享接口。 2、内部系统间业务服务调用接口 主要是各个子系统间业务服务调用接口。
1.2.2外部接口 本项目是在文艺资源系统整合一期基础上建设，主要接口来源于整合一期中文艺资源数据库系统间的接口。 1、与文艺资源数据库系统对接接口 与文艺资源数据库系统对接，实现会员数据、作品数据交换至文艺资源数据库。 2、与身份认证系统对接接口 与身份认证系统对接，实现用户统一认证管理。 1.3接口设计模式 1、接口定义 接口是指用于完成各系统间和系统内部数据传递的接口。在系统中通常设计成一个数据库文件或接口转换模块，传出数据的系统通常对数据事先进行必要的加工处理，需要接收数据的系统按照用户的要求（用户事先定义的数据模式），通过接口完成数据传递的任务。 （1）数据模式 接口的核心是数据模式，所谓数据模式是指应用系统对要传递的数据应在数据的来源、内容、定义、分类、汇总、数据格式、数据去向等方面的处理上做出相应的规定。一般情况下数据模式是在软件初始化阶段由用户设定的，投入应用时大量的数据采集完全自动化。同时根据系统的实际需要用户也可以对数据模式进行修改和维护，甚至重新定义。 （2）传递数据的形式 对于传递数据的形式，不同的软件系统可采用不同的策略：一种是由接收数据的系统采取主动按照数据接口定义到对方系统去识别、采集。一种是由要传出数据的系统先对数据进行加工，然后按照数据接口定义将数据传递过去。如果是系统内接口，一般采用的是第一种，系统内外系统间的数据传递一般是第二种。 2、系统内部接口 系统内部接口适合于本项目内各业务系统之间的数据传递，要传递的数据的格式、内容基本上相同，无需再加工处理。接口不是系统之间的数据传递，而
WORD格式可编辑 系统对接设计 1.1.1 对接方式 系统与外部系统的对接方式以web service方式进行。 系统接口标准： 本系统采用SOA体系架构，通过服务总线技术实现数据交换以及实现各业务子系统间、外部业务系统之间的信息共享和集成，因此SOA体系标准就是我们采用的接口核心标准。主要包括： 服务目录标准：服务目录API接口格式参考国家以及关于服务目录的元数据指导规范，对于W3C UDDI v2 API结构规范，采取UDDI v2的API的模型，定义UDDI的查询和发布服务接口，定制基于Java和SOAP的访问接口。除了基于SOAP1.2的Web Service 接口方式，对于基于消息的接口采用JMS或者MQ的方式。 交换标准：基于服务的交换，采用HTTP/HTTPS作为传输协议，而其消息体存放基于SOAP1.2协议的SOAP消息格式。SOAP的消息体包括服务数据以及服务操作，服务 数据和服务操作采用WSDL进行描述。 Web服务标准：用WSDL描述业务服务，将WSDL发布到UDDI用以设计/创建服务，SOAP/HTTP服务遵循WS-I Basic Profile 1.0，利用J2EE Session EJBs实现新的业务服务，根据需求提供SOAP/HTTP or JMS and RMI/IIOP接口。 业务流程标准：使用没有扩展的标准的BPEL4WS，对于业务流程以SOAP服务形式进行访问，业务流程之间的调用通过SOAP。 数据交换安全：与外部系统对接需考虑外部访问的安全性，通过IP白名单、SSL 认证等方式保证集成互访的合法性与安全性。 数据交换标准：制定适合双方系统统一的数据交换数据标准，支持对增量的数据自动进行数据同步，避免人工重复录入的工作。 1.1.2 接口规范性设计 系统平台中的接口众多，依赖关系复杂，通过接口交换的数据与接口调用必 须遵循统一的接口模型进行设计。接口模型除了遵循工程统一的数据标准和接口专业知识整理分享
计算机常见外部接口图解 3.5mm插头 USB接口 串口 VGA接口 网卡（LAN）接口 并口 电脑内数据接口 IEEE1394接口 eSATA接口 Micro-USB DVI HDMI
3.5mm插头 最常见的立体声耳机分三层，也有两层的，每一层都有对应的功能，要DIY的话一定要分层。标准分布为“左右地红白”（从端部到根部依次是左声道、右声道、地线，其中左声道常用红色线皮，右声道常用白色的）。 最常见的是银白色的和铜黄色的，银色的是铜镀银，铜黄色的就是铜。由于银的稳定性和电子工程性优于铜，所以铜镀上银后可以升级使用该插头设备的用户体验。 USB接口 USB是一种常用的pc接口，他只有4根线，两根电源两根信号，故信号是串行传输的，usb接口也称为串行口，usb2.0的速度可以达到480Mbps。可以满足各种工业和民用需要.USB接口的输出电压和电流是： +5V 500mA 实际上有误差，最大不能超过+/-0.2V 也就是4.8-5.2V 。usb接口的4根线一般是下面这样分配的，需要注意的是千万不要把正负极弄反了，否则会烧掉usb设备或者电脑的南桥芯片：黑线：gnd 红线：vcc 绿线：data+ 白线：data-
USB接口定义图 USB接口定义颜色 一般的排列方式是：红白绿黑从左到右 定义： 红色－USB电源：标有－VCC、Power、5V、5VSB字样 白色－USB数据线：（负）－DATA-、USBD-、PD-、USBDT- 绿色－USB数据线：（正）－DATA+、USBD+、PD+、USBDT+ 黑色－地线： GND、Ground USB接口的连接线有两种形式，通常我们将其与电脑接口连接的一端称为“A”连接头，而将连接外设的接头称为“B”连接头(通常的外设都是内建USB数据线而仅仅包含与电脑相连的“A”连接头)。 USB接口是一种越来越流行的接口方式了，因为USB接口的特点很突出：速度快、兼容性好、不占中断、可以串接、支持热插拨等等，
第十二章系统内外部接口划分及配合措施 1.系统内外部接口划分 1.1光伏发电系统并网许可证办理 ＞业主负责:光伏发电系统并网许可证的申报和办理。 ＞我公司负责：光伏发电系统并网许可证相关技术资料的编制和技术支持，解答并网光伏发电系统并网的技术问题，全力配合申报过程中的一切事务。 1.2申请上网电价的划分 ＞业主负责:光伏发电系统并网上网电价的申报和办理。 ＞我公司负责：协助光伏发电系统并网上网电价申请的相关技术资料编制和技术支持，并协助申请过程中有关事项支持工作。 1.3光伏发电系统并网点的划分 ＞业主负责:将并网线路电缆敷设引入光伏发电系统控制室。 ＞我公司负责:我公司负责并网电缆接线端子的制作和电缆接线。 1.4光伏发电系统通讯系统接口划分 ＞业主负责：为每个控制室和中控室提供局域网络接口和电源。 ＞我公司负责:我公司负责整个系统的连接，并提供通信协议、标准的通讯接口。 1.5逆功率保护功能接口划分 ＞业主负责:提供每个并网点处低压母线电流传感器安装位置。 ＞我公司负责：曲我公司负责接入交流控制柜中； 1.6屋顶光伏组件安装面接口划分 ＞业主负责：屋顶钢结构设计、施工和屋顶钢结构要求加密的標条（详见图纸）。 ＞我公司负责:屋顶钢结构標条上光伏组件支架的安装，并负责与安装面连接的不锈钢螺栓、光伏组件支架、光伏组件支架安装连接的不锈钢螺栓。
1.7光伏系统线路过墙过楼板预留孔洞接口划分 ＞业主负责:光伏系统电缆线路经过的路径位置和过墙、过楼板的预留孔洞。＞我公司负责：光伏发电系统电缆桥架和电缆敷设山我公司负责供货和施工；协 助建筑电气施工单位对预留孔洞的定点和施工检查。 2.配合措施 我公司如有幸中标，我公司将全力以赴的配合与其他专业配合工作。釆取配合措施如下： 2.1并网申请配合措施 我公司将安排具有并网申请经验的专业工程师，配合光伏发电系统并网申请的有关事务，协助提供和编制并网申请相关的技术资料和申请文件。 2.2申请上网电价配合措施 业主需要申请上网电价，我公司将安排具有经验的人员，全力配合业主对上网电价申请工作，协助提供相关的技术资料，协助申请上网电价全过程中有关事配合工作。 2.3光伏发电系统并网点配合措施 1）设计配合： 我公司将派驻具有光伏发电系统丰富设计经验的设讣工程师，配合建筑电气设计单位对并网线路的深化设计和相关接口的工作。 2）施工配合： 我公司将派驻具有光伏发电系统丰富施工经验的匸程师到施工现场，配合建筑电气施工单位对并网线路敷设的技术指导，协助解决施工过程出现的问题。 2.4光伏发电系统通讯系统接口配合措施 我公司将派驻具有光伏发电系统丰富设计经验的设计工程师配合建筑电气设讣单位对光伏电站通讯系统的深化设讣和相关接口工作。协助建筑电气施工单位的施工工作。 2.5逆功率保护功能接口配合措施 我公司将派驻具有光伏发电系统丰富设计经验的设计工程师配合建筑电气设讣单位对并网点处相应低压配电柜的深化设计和相关接口工作。协助建筑电气施工单位的施工工作。
系统对接设计 1.1.1 对接方式 系统与外部系统的对接方式以web service方式进行。 系统接口标准： 本系统采用SOA体系架构，通过服务总线技术实现数据交换以及实现各业务子系统间、外部业务系统之间的信息共享和集成，因此SOA体系标准就是我们采用的接口核心标准。主要包括： 服务目录标准：服务目录API接口格式参考国家以及关于服务目录的元数据指导规范，对于W3C UDDI v2 API结构规范，采取UDDI v2的API的模型，定义UDDI的查询和发布服务接口，定制基于Java和SOAP的访问接口。除了基于SOAP1.2的Web Service 接口方式，对于基于消息的接口采用JMS或者MQ的方式。 交换标准：基于服务的交换，采用HTTP/HTTPS作为传输协议，而其消息体存放基于SOAP1.2协议的SOAP消息格式。SOAP的消息体包括服务数据以及服务操作，服务数据和服务操作采用WSDL进行描述。 Web服务标准：用WSDL描述业务服务，将WSDL发布到UDDI用以设计/创建服务，SOAP/HTTP服务遵循WS-I Basic Profile 1.0，利用J2EE Session EJBs实现新的业务服务，根据需求提供SOAP/HTTP or JMS and RMI/IIOP接口。 业务流程标准：使用没有扩展的标准的BPEL4WS，对于业务流程以SOAP服务形式进行访问，业务流程之间的调用通过SOAP。 数据交换安全：与外部系统对接需考虑外部访问的安全性，通过IP白名单、SSL 认证等方式保证集成互访的合法性与安全性。 数据交换标准：制定适合双方系统统一的数据交换数据标准，支持对增量的数据自
XXXXXX管理系统 数据接口说明 版本：1.0 修改时间：2014年11月 定稿时间：*年*月
目录 目录 (2) 一、主要内容 (2) 二、流程文件及风险点数据接口 (2) （1）流程文件及风险点概念说明 (2) （2）使用过程说明 (3) （3）接口说明 (3) 2.3.1. 接口概述 (3) 2.3.2. 接口调用方式 (4) 2.3.3. 接口文件概述 (5) 一、主要内容 门户对外提供如下接口： XXXXXX系统流程文件及风险点数据接口 二、流程文件及风险点数据接口 （1）流程文件及风险点概念说明 流程文件
?指包含业务流程的制度文件 ?一个业务流程可对应多个子流程，子流程即为流程文件所包含 的各个业务流程图 ?一个子流程一定被包含在某个业务流程关系的节点 风险点 ?指流程文件中的子流程在某个环节可能涉及到的风险 ?一个业务流程文件可对应多个子流程，一个子流程可以对应多 个业务环节，一个业务环节可对应多个风险点 （2）使用过程说明 使用过程如下： ?外部系统开发者和XX系统管理员协商，确定外部系统的IP 地址及权限协议等（XX系统提供的是FTP文件传输协议提 供数据） ?外部系统想要获取文件必输建立与XX系统连接的FTP协议 通道 ?外部系统获取的文件为完整的XML文件，通过FTP下载到 本地后解析能获取完整的数据 （3）接口说明 2.3.1.接口概述 由于XX系统中已入库的流程文件及风险点不允许二次修改，所
以不提供修改增量数据，但提供废止、删除增量数据。数据接口如下： ?导出完整的流程文件及风险点数据 外部系统可以通过XX接口获得一整套全量数据，从而建立 起本系统所需要的流程文件及风险点，而无须从零开始建 立。 ?导出废止流程文件增量数据 外部系统还可以通过XX接口获得这些流程文件的最新状 态，是否已被废止。使得外部系统可以方便地和XX数据保 持一致。 ?导出删除流程文件增量数据 外部系统还可以通过XX接口获得这些流程文件的最新状 态，是否已被删除。使得外部系统可以方便地和XX数据保 持一致。 2.3.2.接口调用方式 数据导出接口是以FTP方式提供的，需要通过FTP协议向XX系统发送请求，服务器地址是：http://服务器域名/CMS/$DATE/cmpfile.xml URL解释： http://服务器域名/cms：XX系统的访问地址 $DATE：XX系统建立的当天的文件夹，通过日期文件夹管理数据，避免数据重复以及提供了完整的历史记录
系统接口规范以及常见的接口技术概述一、基本要求： 为了保证系统的完整性和健壮性，系统接口应满足下列基本要求： 1.接口应实现对外部系统的接入提供企业级的支持，在系统的高并发和大容量 的基础上提供安全可靠的接入； 2.提供完善的信息安全机制，以实现对信息的全面保护，保证系统的正常运行， 应防止大量访问，以及大量占用资源的情况发生，保证系统的健壮性； 3.提供有效的系统的可监控机制，使得接口的运行情况可监控，便于及时发现 错误及排除故障； 4.保证在充分利用系统资源的前提下，实现系统平滑的移植和扩展，同时在系 统并发增加时提供系统资源的动态扩展，以保证系统的稳定性； 5.在进行扩容、新业务扩展时，应能提供快速、方便和准确的实现方式。 二、接口通讯方式： 接口基本采用了同步请求/应答方式、异步请求/应答方式、会话方式、广播通知方式、事件订阅方式、可靠消息传输方式、文件传输等通讯方式： 1.同步请求/应答方式：客户端向服务器端发送服务请求，客户端阻塞等待服 务器端返回处理结果； 2.异步请求/应答方式：客户端向服务器端发送服务请求，与同步方式不同的 是，在此方式下，服务器端处理请求时，客户端继续运行；当服务器端处理结束时返回处理结果； 3.会话方式：客户端与服务器端建立连接后，可以多次发送或接收数据，同时 存储信息的上下文关系； 4.广播通知方式：由服务器端主动向客户端以单个或批量方式发出未经客户端 请求的广播或通知消息，客户端可在适当的时候检查是否收到消息并定义收到消息后所采取的动作； 5.事件订阅方式：客户端可事先向服务器端订阅自定义的事件，当这些事件发 生时，服务器端通知客户端事件发生，客户端可采取相应处理。事件订阅方式使客户端拥有了个性化的事件触发功能，极大方便了客户端及时响应所订阅的事件； 6.文件传输：客户端和服务器端通过文件的方式来传输消息，并采取相应处理；
第十五章与外部系统的接口 15.1 概述 SUPER POWER8000系统采用WindowsNT、Windows2000作为操作系统，由于操作系统本身是多用户、多任务的，因此在系统中实现应用程序之间的数据交换是比较方便的。目前Windows提供有DDE、OLE （包括OPC）、ODBC等几种标准来支持应用程序之间的数据交换。 同时，SUPER POWER8000系统可根据实时数据库提供的数据访问接口可为各种外部设备和应用软件提供数据交互，如模拟屏、大屏幕投影仪、上级调度、微机五防、MIS、负荷控制、抄表、客户中心、配网自动化等，从而将这些系统和SUPER POWER8000系统融为一体。 DDE是英文dynamic data exchange的缩写，即动态数据交换，它是最早的Windows操作系统面向非编程程序用户的程序间通信标准，通信效率低下，当通信数据量大时数据刷新速度慢。因此SUPER POWER8000系统主要考虑OLE和ODBC标准。 15．2 OLE及控件标准 OLE是英文object linking and embedding （对象的连接与嵌入）的缩写，最早使用于在一个程序中引用另一个程序中某个对象时直接用指针指向对象，而不必将被应用的对象拷贝道程序中。例如，一个电子表格（比如Excel）对象可以直接被连接到字处理程序（比如Word）中，通过这样的连接后，在Word中可以直接对Excel进行
编辑，就好像他在Word当中一样；反过来，在Excel中编辑一个被嵌入到Word中的表格时，修改结果也会即刻被送达Word文档。 后来发布的OLE2将原来的概念做了较大的扩充，制定了规范的接口，在此基础上产生了组建对象模型（component object model，COM）、ActiveX控件、DCOM（distributed COM）技术，使得程序间交换数据有了更高效的手段。COM实际上是一种协议或接口标准，他负责将OLE对象连接起来，要想能够正确调用OLE对象就必须遵从这种标准。 OPC（OLE for process control，及应用于工业控制的OLE标准）是由国际上多家知名软硬件大公司（如Microsoft、Interlution、GE等）联合发起制定的一个接口标准。它是为了解决应用软件与各设备驱动程序的通信而产生的一项工业技术规范和标准，它采用客户/服务器体系，基于Microsoft的OLE/COM技术，为硬件厂商和应用软件开发者提供了一套标准的接口。这样硬件厂商只需开发一套符合OPC Server规范的程序组就可以满足不同用户的需要，无需考虑工程人员需求；而应用软件开发者只需编写一个符合OPC Client规范的接口就可以和任何硬件设备进行通信无需重写大量的设备通信驱动程序；从而工程人员也无需再考虑应用程序是否支持所选硬件的问题，有了更多的选择余地。OPC V1.0只支持实时数据的访问控制，V2.0还支持历史数据的访问控制，从而为OPC的适用范围提供了更大的空间。OPC技术规范由OPC基金会负责管理和升级维护，任何单位均可加入，只需每年缴纳少量的费用。
目录 统一接口平台 接口平台架构 浙江移动电子渠道各子业务系统通过统一接口层获取数据，不直接与外部系统接口打交道。统一接口层通过多种方式与外部系统联接、获取数据并向各子业务系统提供XML数据格式包，将外部系统有效地隔离在业务系统之外。第三方业务系统需要请求的外部接口需要在统一接口层注册，并生成配置文件；每次访问都会被有效地记录，实行监管。 电子渠道系统统一接口平台实现构架如下 在炎黄新星统一接口平台中，接口层为电子渠道系统提供接口访问支撑，提供统一的双向访问接口。应用逻辑层通过调用接口层与各外部系统进行交互，向其他系统传递数据并得到反馈。其他系统通过接口层主动访问电子渠道系统，并得到反馈。 逻辑架构图
接口调度层主要的功能是根据外部业务系统的服务请求来进行接口调度管理。 数据封装层对接口协议进行适配，以达到接口层灵活的扩展新的外部接口； 接口适配器中会根据配置规则的要求实现对外部接口调用超时以及重发的处理。 协议适配层的功能完成内部协议（外部系统和接口层之间的数据传输协议）到接口适配器协议的转换。 功能模块图 实现方式及流程 接口主要分为两类：包括主动发起请求方式、被动接收请求方式接口；主动请求类接口主要是电子渠道接口平台向外围系统发起接口请求的，包括与BOSS 的接口、银联接口、短信/WAP网关接口、第三方支付系统接口等；被动请求类接口主要是第三方外围系统向电子渠道发送的接口请求，包括业务查询、开户、办理、支付等请求。 接口层作为Client端主动发起服务请求时，要按照接收服务请求方的协议进行数据交互；作为Server端被动接收服务请求时，要承担服务请求端的协议适配功能。 以下以查询类业务为例，说明数据的交互流程。 功能实现 调度管理