文档库 最新最全的文档下载
当前位置:文档库 › 研究基于IVI-CO架构M的可互换仪器驱动架构

研究基于IVI-CO架构M的可互换仪器驱动架构

研究基于IVI-CO架构M的可互换仪器驱动架构
研究基于IVI-CO架构M的可互换仪器驱动架构

基于IVI-COM的可互换仪器驱动架构研究

王伟

(北京航天测控技术开发公司,北京 100037)

摘要:文章介绍了IVI仪器驱动的体系结构,说明了IVI-COM驱动程序的工作原理,并以VXI数字万用表AMC2301和开关模块AMC2616为典型实例,简要说明了在VC环境下实现IVI-COM仪器类接口操作具体仪器的使用方法。

关键词:IVI-COM;仪器驱动程序;类接口

1 IVI仪器驱动

软件是虚拟仪器的灵魂,而仪器驱动又是虚拟仪器软件的核心,它以高级的抽象的仪器映像方式将用户界面与仪器的硬件联系起来。长期以来,出于设备废行、升级而引起的硬件设备的变更常常迫使系统人员对现有测试系统软件进行重复的修改和编译工作,系统的稳定性很差,仪器的互换能力很弱。

1998年8月,为了进一步提高仪器驱动程序的执行性能,达到真正的仪器互换,由九个公司成立IVI(Interchangeable Virtual Instrumentation)基金会,在VPP的基础上为

标准,使应用程序可以实现完成独

立于硬件,而不管其是何种总线接

口,并增加了仪器仿真、状态缓存

等机制,进而大大提高了仪器的执

行效率。

1.1 IVI仪器驱动程序的结构

图1是IVI仪器驱动程序的结

构模型,该模型同VPP模型相比

较,其主要区别在于:(1)函数体

图1 IVI仪器驱动程序的结构模型

中增加了一组具有标准应用程序接口的属性函数和与属性相对应的回调函数;(2)引入面向对象技术中的属性管理机制,增加了一个对各属性进行管理的IVI引擎。

IVI引擎常以动态连接库的形式提供,其运行对用户是透明的。所有用于创建仪器驱动程序的函数以IVI库或者IVI引擎导出函数的形式提供给仪器驱动程序开发者,同时函数库也提供给用户应用层用于分析和显示仪器驱动程序信息函数。

1.2 IVI仪器驱动程序的特点

由于IVI提供了一种目前最先进的虚拟仪器驱动程序开发技术,因此基于IVI模型开发的驱动程序除具有VPP驱动程序所具有的特点外,还具有如下的特点:1)具有仪器级的可互换性。根据IVI类驱动器编写的测试代码,在仪器硬件被另外一个同类的仪器模块代替时,不必经过修改便可直接调用。

2)高性能的具有状态存储机制的程序结构。IVI引入了面向对象的属性管理机制,其模型中增加的IVI引擎可实现状态存储功能。对于VPP驱动程序来说,总是假设仪器状态是未知的,因此,每个测量函数在进行测量操作之前都要对仪器进行设置,而不管仪器在此之前是否被配置过。而IVI中通过属性模型,驱动程序能自动存储仪器的当前状态。一个IVI仪器驱动程序函数只有在仪器设置和函数所要求的不一致时,才执行I/O操作,这样IVI引擎通过跟踪仪器的硬件设置,避免发送冗余的仪器配置命令,从而可以优化程序运行时的性能,这是比VPP驱动程序性能优越的一个突出特点。

3)具有仪器的仿真能力。IVI模型可以在没有仪器硬件的情况下使用驱动程序建立应用程序。在这种仿真状态下,驱动程序不执行仪器I/O而仅利用软拷贝来进行处理,它检查输入参数并且产生仿真的输出结果。有了这些仿真数据,开发者在没有仪器硬件的情况下也能为仪器开发应用代码。

4)具有多线程的安全性。

5)具有范围检查、状态缓存以及其它的调试和开发功能。

2 用COM实现的IVI

IVI基金会提出基于COM的IVI驱动程序,这并非想取代基于C的IVI驱动程序,而是作为一个必然的发展,以满足A TE(自动测试环境)领域的各种要求。

2.1 引入COM的技术依据

COM接口是句法和语义上的组合,句法可由IDL(接口描述语言)来精确地获取。语义上则需要有一定的模糊性,以使多种对象能使用同一个接口。这样COM接口是用于实现有精确句法、在类中可以构造各种仪器的IVI类定义的理想工具。在COM接口中,并不像C语言要求的,需要有一个前缀,COM并不需要类驱动程序就提供了句法上的可互换性。

COM接口隐藏了执行代码和详细的算法,这就意味着仪器生产商可以利用各种适合

他们的方式来实现接口。COM 接口是用COM 类和实例化的COM 对象来实现的。这使得COM 驱动器可以在内部执行实例的数据,从而克服了VPP 和IVI 中的一个缺陷。COM 的封装性也使版本问题变得简单了,只要保持其接口不变就可以随意替换COM 对象,不需要进行编译就可以把它集成到现存的客户测试程序中去。 2.2 应用开发环境的要求

IVI-COM 驱动器必须可以在所有的比较流行的自动测试应用开发环境中使用,包括:LabView 、HP VEE 、VB 、C 、C++、VC++、LabWindows/CVI 等。每种环境对于已经存在的COM 的支持都有其自身的特点。值得注意的是,一些语言在数据类型方面存在很大限制,这在一般的应用中可能暴露出很多致命的缺陷,但是IVI-COM 相对来说对数据类型要求要简单一些。事实上,所有用于现有的IVI 仪器的数据类型都可以用变量来代替。这样就保证了IVI 驱动器可以被任何应用程序开发环境所使用。

3 IVI 仪器驱动的使用

3.1 仪器类-标准仪器编程接口

因为所有的仪器不可能具有相同的功能,因此不可能建立一个单一的编程接口。正因为如此,IVI 基金会制定的仪器规范被分为基本能力和扩展属性两部分。前者定义了同类

仪器中绝大部分仪器所共有的功能和属性;后者着重体现了每类仪器的特殊功能和属性。仪器类被定义成仪器属性

和对这些属性编程的API 的集合,这个类也包含了程序员设值属性和从仪器上获取数据的函数。图2为IVI 仪器驱动的体系结构图。

IVI 技术通过定义通用仪器类的标准仪器驱动器的编程接口,提高了测试软件的通用性,从而极大的降低了测试软件的开发周期和研发成本。IVI 技术规定了基本函数调用的标准化,并且标准化了一些设置以及允许数据,因

而基于IVI 技术的产品可以为测试系统的开发节约大量的成本。一个特定的IVI 仪器驱动器,包括一个特定仪器模块信息,如命令字符串、解析代码以及仪器设置的有效范围。 3.2 系统配置

为了在测试程序中使用IVI 类驱动程序就必须首先配置系统以便类驱动可以与具体的仪器驱动进行交互,这一步是通过IVI 基金会提供的IVI 共享组件Configuration Server 来完成的。

IVI Configuration Server 为IVI 应用程序提供系统数据库服务,特别是它提供系统的初始化和配置信息。Configuration Server 是由configuration store XML

文件和一个可以访问、

图2 IVI 仪器驱动体系结构图

存取操作XML文件的COM对象组成。图3为configuration store XML文件内容片断。

MAX是所有硬件以及相关软件的国际仪器标准配置工具,首先配置的是逻辑名,逻辑名是指在应用中所使用的虚拟仪器。一个虚拟仪器是物理仪器、仪器驱动器、选择设置的组合。改变逻辑名所指的仪器,就可以改变仪器而不改变测试程序,这个机制是通过类驱动器中的初始化函数引发的。例如:当使用一个类驱动器初始化一个仪器时,并没有将形如:“GPIB:2:INSTR”的标准资源字符串传递给驱动器,而是给出了一个“DMM1”这样的逻辑名。configuration store XML文件中包含了仪器驱动器的位置以及初始化配置信息,其中:

(1)逻辑名文件夹包含了用户定义的所有逻辑名,这些逻辑名用来区分仪器中用到的仪器,文件夹包含了驱动器属性的初始化信息。如:State caching,simulation等等。

(2)仪器驱动器文件夹包含了有关在哪里能找到每一个虚拟仪器文件夹中的仪器的具体驱动器信息。文件夹包含的信息是以VISA资源形式描述的物理仪器地址。这些文件夹的信息随着系统增加驱动器而更新,需要更换仪器,只要简单的在逻辑名文件夹处改变具体的仪器对应的逻辑名即可。

3.3 IVI-COM仪器驱动程序的工作过程

图4为IVI-COM仪器驱动程序调用过程的体系结构图。图中虚线框中部分代表IVI

仪器驱动,它既是一个仪器类驱动接口,也

是一个仪器专用驱动接口。与IVI-C不同点

在于,仪器类驱动接口和仪器专用接口都封

装在同一个仪器驱动COM对象中。因此应

用程序对IVI-COM仪器驱动组件既可以使

用类驱动接口进行仪器操作,也可以使用专

图4 IVI-COM仪器驱动程序调用过程体系结构图

图3 configuration store XML片断

用驱动接口进行操作。

4 在VC++6.0中开发IVI-COM 应用示例

本示例通过访问IVI-COM 驱动程序的仪器类接口,来对具体测试仪器(测量模块)进行操作,完成测试仪器(测量模块)测量功能。开发步骤如下:

(1)创建一个基于对话框的MFC 应用程序

(2)在窗体中添加两个按钮Read 和Exit ,并添加一个编辑框,如图5。 (3)在应用程序的InitInstance()函数中开头部分添加代码“AfxOleInit();” (4)在对话框类头文件中导入COM 组件,如图6。 (5)在对话框类中添加成员变量,代码如下:

IIviSessionFactoryPtr SessionFactoryPtr; //IVI 共享组件SessionFactory 智能指针 IIviDmmPtr DmmPtr; //万用表仪器类接口智能指针

(6)在对话框OnInitDialog()函数中添加代码,如下:

HRESULT hr;

hr = SessionFactoryPtr.CreateInstance(__uuidof(IviSessionFactory)); if (SUCCEEDED(hr)) { try { DmmPtr =SessionFactoryPtr->CreateDriver("AmcDmm");//AmcDmm 为逻辑名称

DmmPtr->Initialize("AmcDmm",V ARIANT_FALSE,V ARIANT_FALSE,"");

} catch (_com_error er) { BSTR Desc;

er.ErrorInfo()->GetDescription(&Desc); CString ErrorString(Desc);

AfxMessageBox(ErrorString);

图5

图6

exit((int)er.Error());

}

} else { AfxMessageBox("Failed to create session factory instance!"); exit(hr);

}

(7) 在按钮Read 点击事件下添加代码,如下:

double dRead; CString strRead; try{ DmmPtr->Configure(IviDmmFunctionDCV olts,IviDmmAutoRangeOn,0); dRead = DmmPtr->Measurement->Read(2500); strRead.Format("%lf",dRead);

m_ctlDisplay.SetWindowText(strRead);

} catch (_com_error er) { BSTR Desc;

er.ErrorInfo()->GetDescription(&Desc); CString ErrorString(Desc); AfxMessageBox(ErrorString); exit((int)er.Error());

}

(8) 在按钮Exit 点击事件下添加代码,如下:

DmmPtr->Close();

OnOK();

代码添加完成,对工程进行编译、连接、执行,在应用程序用户界面中点击Read 按钮,对话框中显示测量结果,如图7。

5 结束语

IVI-COM 使ATE 设备中的可互换性问题变得简单,通过对IVI Configuration stroe XML

的配置来完成同类不同型号的仪器更换,改变了原来由于仪器驱动程序不同,测试程序需要重新编写的不利状况,为测试系统的维护和更新提供了更为便利的手段。

图7

参考文献:

[1] IVI Specifications Revision 1.0 https://www.wendangku.net/doc/3c11676532.html,, August 6,1998.

[2] 潘爱民 COM原理与应用 [M] 清华大学出版社 1999.1.27-63.

企业管理沟通模式与六种基本组织结构

优点是一个下级只受一个上级领导管理,上下级关系简明清晰,层级制度严格明确,保密程度好,决策与执行工作有较高效率;管理沟通的信息来源与基本流向固定,管理沟通的渠道也简单固定,管理沟通的速度和准确性在客观上有一定保证。缺点是管理无专业分工,各级管理者必须是全能管理者,各级管理者负担重,但企业较大时,难以有效领导与管理;管理沟通的信息来源与基本流向被管理者死死控制,并且管理沟通的速度和质量严重依赖于直线中间的各个点,信息容易被截取或增删,造成管理沟通不顺畅或失误。 从管理理论与实践上来讲,直线型组织结构与链型管理沟通渠道模式在一定的条件下,均有其存在的合理性及优势。在人数不多的小企业或信息需要严格分层极保密的组织如小型军队中,直线型组织结构与链型沟通渠道模式可以简化管理与沟通过程,有助于产生较高的组织工作效率与效益。 2,职能型组织结构与管理结构 第二种基本的企业组织结构与管理结构是职能型组织管理结构。职能型组织与管理结构是在直线型的基础上,将最高管理者与中层管理者的管理工作按照其职能不同,划分成几个部分,分别由不同的管理者来管理的一种组织管理结构。 在职能型组织管理结构下,一个下级可能需要面对两个或多个专业分工不同的上级,从他们那分别接受不同专业范围内的不同工作指令,但所有这些工作指令都是由这一个

下级独立完成。与此相对应的管理沟通模式,在大多数情况下,以链型与轮型交织在一起的链轮混合型沟通渠道模式居多。 链轮混合型沟通渠道模式是混合型沟通渠道模式的一种。它是指在一个大的沟通渠道模式中,分别包含了一两个或多个链型与轮型沟通渠道小模式的沟通渠道模式。例如,由最高管理者往下时是轮型沟通渠道模式,一个管理沟通中心连接着多个管理沟通节点;而在最高管理者与最低管理者之间有时又是利用链型管理沟通渠道模式在逐层传递信息;具体到了最低管理者管理其下属时,其管理沟通模式又变成了一个人面对许多人沟通的轮型沟通渠道模式,等等。 链型和轮型管理沟通渠道模式,多链型和多轮型管理沟通渠道模式,以及由它们混合而成的链轮混合型沟通渠道模式,都有一个共同的特点,那就是它们的沟通在方向上,基本上属于上行或下行沟通,同一层级之间的平行管理沟通比较少或没有,交叉沟通没有被纳入沟通设计内容。从理论上讲,它们都主要适用于管理比较简单明了的规模比较小的企业。 职能型组织管理结构,有时也会对应着梯型、多梯型或类似梯型的管理沟通渠道模式。如企业设立一总经理,下设分管业务与财务的两名副总经理,两名副总各自再分管理三至五个大的部门,而副总与副总之间,部门与部门之间,又存在着平行的管理沟通。一旦企业中同一层级中规定必须存在着平行方向的管理沟通,以协调相关部门的运作,则完全可以认为,该企业管理沟通模式中,存在着梯型或类似梯型的管理沟通。

传统企业组织结构模式的比较分析.doc

传统企业组织结构模式的比较分析 0 组织结构概述 市场交易的内部化,客观上要求企业建立一个有效的、较为发达的层级组织,以防止由于行政协调机制无效而造成的资源配置不合理。企业管理没有什么普遍适用的、最好的管理理论和方法,而应该根据企业所处的内部条件和外部环境权宜应变,灵活掌握。权变理论将企业看作是一个开放的系统,究竟应采用何种组织结构,应视企业具体情况而定,不可能有普遍适用的结构模式。赫里格尔和斯洛坎姆根据外部环境和内部选择两方面因素,将传统的企业组织结构分为高度集权制、直线职能制、矩阵组织制、多分部制(又称事业部制)四种类型。但随着经济的不断发展以及经济全球化趋势的不断推进,传统组织结构遭遇了越来越多的挑战,这种挑战不仅来自于管理理论研究领域,也同样来自于管理的实践。 1 传统组织理论的分析 1.1 古典组织理论分析 古典组织理论包括20世纪初期由泰罗等人创立的科学管理理论、法约尔的行政管理理论和由马克斯?韦伯发展起来的

官僚模型理论。古典组织理论的主要贡献在于第一次运用科学的方法将组织问题系统化、理论化与科学化。 泰罗的科学管理理论包括着组织理论的早期萌芽,其组织理论思想主要有:设置计划部门,实行职能制,和实行例外原则。法约尔的行政管理理论中的主要组织理论有:①从组织管理过程的角度提出了管理的5项基本职能,②从组织职能角度提出了管理的14条基本原则,③提出了建立层级组织的管理幅度概念,④研究了企业职能机构的设置,构建了直线职能制的组织结构形式,和⑤提出了解决组织内部管理效率问题“法约尔桥”思路。“组织理论之父”马克斯?韦伯是德国著名的社会学家和组织学家,他对组织理论的主要贡献是提出了以“官僚模型”为主体的“理想的行政组织体系”。马克斯?韦伯认为组织结构应该是“科层结构”,并且认为官僚组织是理想的组织模式。马克斯?韦伯认为,法定的权威是构建组织的基石;人类任何一种组织都应该以某种特定的权威为作为基础,缺失了权威的组织不可能统一行动和实现共同的目标;合法的权威基础有三种纯粹形式:合理基础、传统基础与神授基础,但只有法定的权威才是官僚组织的构建基础。 古典组织理论主要是针对组织内部的分工与活动安排来进行研究,这一理论体系为组织内部分工的合理化与活动安排

基于模型驱动架构的电信业务元模型抽象研究

基于模型驱动架构的电信业务元模型抽象研究1 冯跃忠 北京邮电大学网络与交换国家重点实验室,北京(100876) E-mail:yzfeng1981@https://www.wendangku.net/doc/3c11676532.html, 摘要:模型驱动架构(MDA)业务生成技术是新一代的软件开发方法学。在深入分析基于模型驱动的电信业务生成后,文章以SIP Servlet平台为例,给出了一种SIP Servlet平台上的元模型抽象方法,并利用UML Profile的扩展机制在MDA工具上加以实现,实验表明,在SIP Servlet平台上采用此方法抽象的元模型是正确可行的。 关键词:模型驱动架构,元模型抽象,业务生成,SIP Servlet平台 中图分类号:TN911 1.引言 模型驱动架构(Model Driven Architecture, MDA)是对象管理组织(OMG)在2002年初确定的战略方向。在过去的几年中MDA技术取得了很大发展,被应用到诸如电信、航空航天、银行以及医疗卫生行业。作为一种新的业务生成方式,MDA越来越受到人们的关注。将模型驱动技术引入到电信领域,用于新一代电信业务生成具有重大意义。 基于MDA的电信业务元模型抽象是模型驱动业务生成技术的重要研究课题之一。如何抽象出正确且能够覆盖所有电信业务能力的元模型需要深入研究。文章给出一种基于模型驱动架构的电信业务元模型抽象方法,并以SIP Servlet平台为例给出抽象的元模型实例。2.基于模型驱动架构(MDA)的业务生成技术 2.1 MDA概念 MDA定义了开发IT系统的一个标准,使系统功能与功能的实现相分离。最显著的特点是,该标准把关注点放在模型上,模型不再仅仅是描述系统,辅助沟通的设计工具,而是软件开发的核心。MDA把建模语言当作编程语言来用,把软件开发的关注点从代码实现转移到设计和建模上来。 MDA的核心理念是一切以模型为中心,模型是MDA关注的焦点。其最终目标就是使模型可执行。MDA方法在开发过程中提供了更高层次的抽象,其在平台无关模型(PIM)与平台相关模型之间(PSM)的松耦合关系意义十分重大。模型是以精确定义的语言对系统(或系统的一部分)做出的描述【6】。在MDA中建模(描述问题)和模型映射技术(转换问题)是其核心,其技术基础为:统一建模语言(UML)、XML元数据交换(XMI)、元对象设施(MOF)、公共仓库元模型(CWM)。 在某个企业应用MDA方法,其实质就是创建一个新的特定领域的MDA描述语言集,该语言集由某种面向对象建模语言(如UML)的标记组成,比如由几个UML Profile组成的、可以由终端用户使用的集合。所以,MDA方法的核心在于用某种标准的建模语言建模,进行模型之间的转换,从而自动生成代码,提高软件的开发效率以及可重用性。MDA方法的概念模型是开发的基本脉路,如图1所示。 1本课题得到国家自然科学基金项目(60672122)资助。

几种常用的设计模式介绍

几种常用的设计模式介绍 1. 设计模式的起源 最早提出“设计模式”概念的是建筑设计大师亚力山大Alexander。在1970年他的《建筑的永恒之道》里描述了投计模式的发现,因为它已经存在了千百年之久,而现代才被通过大量的研究而被发现。 在《建筑的永恒之道》里这样描述:模式是一条由三个部分组成的通用规则:它表示了一个特定环境、一类问题和一个解决方案之间的关系。每一个模式描述了一个不断重复发生的问题,以及该问题解决方案的核心设计。 在他的另一本书《建筑模式语言》中提到了现在已经定义了253种模式。比如: 说明城市主要的结构:亚文化区的镶嵌、分散的工作点、城市的魅力、地方交通区 住宅团组:户型混合、公共性的程度、住宅团组、联排式住宅、丘状住宅、老人天地室内环境和室外环境、阴和阳总是一气呵成 针对住宅:夫妻的领域、儿童的领域、朝东的卧室、农家的厨房、私家的沿街露台、个人居室、起居空间的序列、多床卧室、浴室、大储藏室 针对办公室、车间和公共建筑物:灵活办公空间、共同进餐、共同小组、宾至如归、等候场所、小会议室、半私密办公室 尽管亚力山大的著作是针对建筑领域的,但他的观点实际上适用于所有的工程设计领域,其中也包括软件设计领域。“软件设计模式”,这个术语是在1990年代由Erich Gamma等人从建筑设计领域引入到计算机科学中来的。目前主要有23种。 2. 软件设计模式的分类 2.1. 创建型 创建对象时,不再由我们直接实例化对象;而是根据特定场景,由程序来确定创建对象的方式,从而保证更大的性能、更好的架构优势。创建型模式主要有简单工厂模式(并不是23种设计模式之一)、工厂方法、抽象工厂模式、单例模式、生成器模式和原型模式。 2.2. 结构型 用于帮助将多个对象组织成更大的结构。结构型模式主要有适配器模式、桥接模式、组合器模式、装饰器模式、门面模式、亨元模式和代理模式。 2.3. 行为型 用于帮助系统间各对象的通信,以及如何控制复杂系统中流程。行为型模式主要有命令模式、解释器模式、迭代器模式、中介者模式、备忘录模式、观察者模式、状态模式、策略模式、模板模式和访问者模式。

集团公司的组织结构种类分析

集团公司的组织结构种类分析 集团公司的组织结构种类分析⒈u型结构:过分集权的组织架构 u型结构也称为“一元结构”,是由泰勒首先提出的,是将管理工作按职能划分为若干个部门,各部门只有很小的独立性,权力集中在企业最高决策者手中,其基本框架可概括为下图u型结构:过分集权的组织架构 这种组织结构的优点是: ①集中领导,统一指挥,便于调配人、财、物; ②职责清楚,办事效率高; ③工作井然有序,整个企业有较高的稳定性。 这种组织结构的缺点是: ①等级分明,层次过多,决策过程缓慢; ②各职能部门以自我为中心,协调困难; ③下级部门的主动性、积极性不能有效发挥; ④机构臃肿,官僚主义严重。 尽管u型结构存在许多缺点,但不失为一种行之有效的组织形式。目前,我国企业中多采用了这一形式。 企业集团各成员企业在纵向合并的初期,一般都采用这种结构。但由于管理幅度过大而造成行政管理费用大于市场交易费、事无巨细的过分集中使企业无力顾及长期发展战略决策与控制、

各职能部门为追求各自的目标而偏离总目标等问题出现后,企业集团将寻求新的组织架构。 ⒉h型结构:过分分权的组织架构 h型结构也称为“控股公司结构”,是一种或分分权的组织架构。历史上的h型结构企业是由众多的中小型u型结构企业横向合并而成的。 母公司持有子公司部分或全部股份,下属各子公司具有独立的法人资格,所从事的产业一般关联度不大,从而形成相对独立的利益中心和投资中心,是与u型集权结构形成鲜明对照的分权结构形式,其基本框架可概括为下图 h型结构:过分分权的组织架构 这种组织结构的优点是: ①包含u型结构,构成控股公司的子公司往往是u型结构; ②子公司保持了相当大的独立性和自由度,有利于提高子公司经营的积极性; ③对分散企业的经营风险积极意义。 这种结构的缺点是: ①母公司的战略、方针等难以向子公司渗透、贯彻; ②母公司的职能部门并不直接为子公司服务,子公司难以充分利用母公司的参谋人员; ③各子公司也要成立股东大会、董事会等机构,增加了管理成本; ④母公司的投资协调比较困难。 尽管h型结构所存在许多缺点,但也不失为一种有效的过渡

PE的几种常见架构

PE的几种常见架构 作者: 张保生金杜律师事务所争议解决组 一、Citi 模式 2002年底,花旗银行与上海浦东发展银行(下称“浦发银行”)达成结为“具有排他性的战略合作伙伴关系”的协议。由于监管政策的限制,花旗银行对浦发银行的股权投资采取分阶段入股的方式,即协议签订后入股5%;在2008前,在政策允许的情况下,花旗银行可增持至14.9%,最终不超过24.9%。根据该协议,在分阶段入股投资的基础上,花旗银行将通过实质性参与实际控制浦发银行的信用卡业务。 经过上述安排,浦发银行信用卡中心名义上设在浦发银行下,实则为按公司化运作的半独立运营中心。一旦政策允许,信用卡中心将独立出来,成立合资公司。而在此之前,双方承担对等的风险、权利和义务。根据协议,花旗银行提供技术和管理,而所有工作人员的工资则计入浦发银行的成本。信用卡中心的首席执行官和四个部门的正职均来自花旗银行,副职则全由浦发银行的人担任,首席执行官向一个由花旗银行和浦发银行各三人组成的“信用卡中心管理委员会”汇报。另外,花旗银行还输出了一支比较有经验的团队,并提供了集团内最新版本的业务系统,所有的数据处理均集中到花旗银行在新加坡的亚太数据处理中心进行。而就与浦发银行在其他业务方面的合作,花旗银行并未投入太大力量,只是提供一些技术援助。 花旗银行对浦发银行的这一投资模式,立足于对被投资企业的某项而非全部业务的深度介入和控制,在时机成熟时便可以延展到其他业务层面。通过这种模式,投资者能以最快、最有效的方式直接进入某项具体业务的市场。PE投资者的先进管理理念和经验与被投资企业的本土优势相结合,能够较容易地在竞争中取得优势地位。此外,尽管投资时存在政策限制,但一旦政策形势发生变化,根据协议安排,合作业务的组织结构和企业性质可以第一时间进行切换,并迅速开展业务,而无需经过过渡期。

八种架构设计模式及其优缺点

八种架构设计模式及其优缺点概述(上) 1. 什么是架构 我想这个问题,十个人回答得有十一个答案,因为另外的那一个是大家妥协的结果。哈哈,我理解,架构就是骨架,如下图所示: 人类的身体的支撑是主要由骨架来承担的,然后是其上的肌肉、神经、皮肤。架构对于软件的重要性不亚于骨架对人类身体的重要性。 2. 什么是设计模式

这个问题我问过的面试者不下于数十次,回答五花八门,在我看来,模式就是经验,设计模式就是设计经验,有了这些经验,我们就能在特定情况下使用特定的设计、组合设计,这样可以大大节省我们的设计时间,提高工作效率。 作为一个工作10年以上的老码农,经历的系统架构设计也算不少,接下来,我会把工作中用到的一些架构方面的设计模式分享给大家,望大家少走弯路。总体而言,共有八种,分别是: 1.单库单应用模式:最简单的,可能大家都见过 2.内容分发模式:目前用的比较多 3.查询分离模式:对于大并发的查询、业务 4.微服务模式:适用于复杂的业务模式的拆解 5.多级缓存模式:可以把缓存玩的很好 6.分库分表模式:解决单机数据库瓶颈 7.弹性伸缩模式:解决波峰波谷业务流量不均匀的方法之一 8.多机房模式:解决高可用、高性能的一种方法 3. 单库单应用模式这是最简单的一种设计模式,我们的大部分本科毕业设计、一些小的应用,基本上都是这种模式,这种模式的一般设计见下图:

如上图所示,这种模式一般只有一个数据库,一个业务应用层,一个后台管理系统,所有的业务都是用过业务层完成的,所有的数据也都是存储在一个数据库中的,好一点会有数据库的同步。虽然简单,但是也并不是一无是处。

优点:结构简单、开发速度快、实现简单,可用于产品的第一版等有原型验证需求、用户少的设计。 缺点:性能差、基本没有高可用、扩展性差,不适用于大规模部署、应用等生产环境。 4. 内容分发模式基本上所有的大型的网站都有或多或少的采用这一种设计模式,常见的应用场景是使用CDN技术把网页、图片、CSS、JS等这些静态资源分发到离用户最近的服务器。这种模式的一般设计见下图:

MDA模型驱动架构

MDA 百科内容来自于: 中科永联高级技术培训中心(https://www.wendangku.net/doc/3c11676532.html,)MDA(Model Driven Architecture)是模型驱动架构,它是由OMG定义的一个软件开发框架。它是一种基于UML以及其他工业标准的框架,支持软件设计和模型的可视化、存储和交换。和UML相比,MDA能够创建出机器可读和高度抽象的模型,这些模型独立于实现技术,以标准化的方式储存。MDA把建模语言用作一种编程语言而不仅仅是设计语言。MDA的关键之处是模型在软件开发中扮演了非常重要的角色。 MDA源自于众所周知的把系统操作的规范从系统利用底层平台能力的方式细节中分离出来的思想,MDA提供了一种途径(通过相关的工具)来规范化一个平台独立的系统、规范化平台、为系统选择一个特定的实现平台,并且把系统规范转换到特定的实现平台。MDA的三个主要目标是:通过架构性的分离来实现轻便性、互操作性和可重用性。 模型驱动架构(MDA)是OMG组织近年来一直热炒的一个新的技术体系,同时也是众多搞软件模型研究人员的一个新热点。MDA(模型驱动)核心的思路是希望通过对商业模型(比如企业信息化或建筑领域的解决方案)的领域研究。进而提炼出一个相对核心的领域模型,同时抽象出一个PIM(平台无关模型)。之后根据不同的开发平台(例如.net或J2EE),应用平台(windows或unix)形成相应的PSM(平台相关模型)。依照相应的工具,例如ArcStyler可以完整地生成相应的代码和软件系统。当然这里只是罗列出一个大致的思路和方法。 1 MDA理论还处在一个探索期,很多理论和方法并不成熟,当然无从谈起有成熟的工具,从目前的趋势而言,从理论到实际的工具都离OMG组织所提出的预想有较大距离,至少还需要数年的努力才能成型。 2目前无论是国外的开源组织还是国内的一些组织对MDA都只是处在一个草创阶段,很多人所谓的应用MDA 其实都只是在MDA的体系中作一个最初的探索和尝试。例如ORM就是在一定层次上实现MDA 在数据库应用方面的探索,但也只是解决了一个实体模型映射的问题。前几天一个面试人员用ArcStyler4.X 做了一个银行POS系统的应用模型,生成了一点还需要修改的框架代码。就告诉我说他已经掌握了MDA,斯等水准真是让我汗颜!佩服! 3 MDA的第一个热点可能是桥接器,而在MDA领域中,映射是个很重要的点,而转换和交互都只是在这个点上的延伸。 4 目前而言,最有可能在MDA体系中得以实现的语言是JAVA。 5 MDA的核心是PIM,因为他是最抽象和协同性最高的。同时就当前形势而言,PIM 也是一个瓶颈!同时就目前的UML2.0(从OMG那里得到最新的)而言,还不足以作为建立整个MDA体系的语言。同时对于MOF中的一些定义似乎还有提升的必要。因为对于整个体系而言,MOF应该更多的作为一个标准,只有在标准成熟的前提下,才有可能产生正确的映射规则。 6 等到MDA风光无限的那天,会使一部分程序员失业,但不会是全部,起码MDA工具要有人做,因为一个MDA工具不足以应付所有的领域。这就好比没有一个财务系统能适应所有的企业一样。因为各个领域的标准化不同。 一、MDA(模型驱动架构)背景 MDA目前在以下领域得到了应用:

模型驱动体系架构 计算无关模型 平台无关模型 模型转换论文

模型驱动体系架构论文:MDA中从CIM到PIM的模型转换研究 【中文摘要】模型驱动体系架构(MDA)是由对象管理组织(OMG) 提出的一种新的软件体系架构,它以模型为核心,模型转换为关键技术,通过模型间的转换来驱动整个软件开发。其中,模型转换是MDA开发方法的重点和难点。在MDA和统一建模语言(UML)的理论基础上, 本文首先研究了MDA中从计算无关模型(CIM)到平台无关模型(PIM) 的模型转换,重点分析了属于CIM范畴的用例图与属于PIM范畴的序列图和活动图的对应关系,并给出了它们之间的转换规则;然后,为了实现转换并保证转换的准确性,本文在国内外已有的研究基础上定义了一种用例描述规范化语言,并基于该语言给出了用例图到序列图及活动图的半自动化转换方法。最后,基于该转换方法,设计和实现了一个模型转换工具,验证了转换方法的可行性和有效性。 【英文摘要】Model Driven Architecture (MDA), proposed by Object Management Group (OMG), is a new kind of software architecture, which focuses on models, taking model transformations as the key technology. By the transformation between models, the development of software is driven. In the development based on MDA, model transformation is a challenging and critical point.Firstly, according to MDA and Unified Modeling Language (UML), this thesis studies an examination of the model transformation from Computation Indep...

XXX有限公司组织架构和业务流程设计

XXX有限公司 组织架构和业务流程设计 (试行) 一、公司主要产品(服务)及用途 (4) 二、公司商业模式 (5) (一)融资:向出资人募集资金 (5) (二)投资:将资金投资到项目或目标企业获取股权(公司控制权) (5) (三)管理:对所投资项目或目标企业进行管理. 5(四)退出:出售被投资项目或目标企业股权获得收益并与出资人分成 (6) 三、公司组织架构 (7) (一)专委会 (8) 1、战略研究委员会 (8) 2、投资发展委员会 (9) 3、风险控制委员会 (10) (二)职能部(参谋本部与执行中心) (11) 1、战略研究部(投资发展研究院) (11)

2、投资管理部 (11) 3、项目管理部 (11) 4、基金管理部 (12) 5、财务审计部 (12) 6、风险控制部 (12) 7、行政管理部 (12) (三)事业部(分子公司与利润中心) (12) 1、发展研究与政商服务事业部(一部) (12) 2、资本经营与产业发展事业部(二部) (12) 3、资产经营与园区经济事业部(三部) (13) (四)合伙公司 (23) 1、四川同兴源置业发展有限公司 (23) 2、岳池都市科技产业园有限公司 (23) 3、四川同兴源企业孵化器管理有限公司 (23) 4、广安临港同兴源置业发展有限公司 (23) 5、四川同兴源商贸有限公司 (23) (五)全资子公司 (23) 1、重庆极和投资顾问有限公司 (23) 2、重庆海晏河清商贸有限公司 (23) 3、重庆极和优创企业孵化器有限公司 (23) 4、重庆龙凤龙文化传播有限公司 (23) 5、重庆极和创科信息技术有限公司 (23)

PE的几种常见架构解析

一、Citi 模式 2002年底,花旗银行与上海浦东发展银行(下称“浦发银行”)达成结为“具有排他性的战略合作伙伴关系”的协议。由于监管政策的限制,花旗银行对浦发银行的股权投资采取分阶段入股的方式,即协议签订后入股5%;在2008年前,在政策允许的情况下,花旗银行可增持至14.9%,最终不超过24.9%。根据该协议,在分阶段入股投资的基础上,花旗银行将通过实质性参与实际控制浦发银行的信用卡业务。 经过上述安排,浦发银行信用卡中心名义上设在浦发银行下,实则为按公司化运作的半独立运营中心。一旦政策允许,信用卡中心将独立出来,成立合资公司。而在此之前,双方承担对等的风险、权利和义务。根据协议,花旗银行提供技术和管理,而所有工作人员的工资则计入浦发银行的成本。信用卡中心的首席执行官和四个部门的正职均来自花旗银行,副职则全由浦发银行的人担任,首席执行官向一个由花旗银行和浦发银行各三人组成的“信用卡中心管理委员会”汇报。另外,花旗银行还输出了一支比较有经验的团队,并提供了集团内最新版本的业务系统,所有的数据处理均集中到花旗银行在新加坡的亚太数据处理中心进行。 而就与浦发银行在其他业务方面的合作,花旗银行并未投入太大力量,只是提供一些技术援助。 花旗银行对浦发银行的这一投资模式,立足于对被投资企业的某项而非全部业务的深度介入和控制,在时机成熟时便可以延展到其他业务层面。通过这种模式,投资者能以最快、最有效的方式直接进入某项具体业务的市场。PE投资者的先进管理理念和经验与被投资企业的本土优势相结合,能够较容易地在竞争中取得优势地位。此外,尽管投资时存在政策限制,但一旦政策形势发生变化,根据协议安排,合作业务的组织结构和企业性质可以第一时间进行切换,并迅速开展业务,而无需经过过渡期。 但是,由于这种模式往往只是将合作与控制限定在一些刚刚起步的新领域,这虽然使得PE 投资者能够较顺利地取得该项业务的控制地位,但如何将对被投资公司的控制从一项具体业务渗透到被投资公司整体,则存在一定难度。 二、红筹模式 红筹模式,是指在海外设立公司,由该公司对国内企业进行控股,以该海外控股公司直接申请上市的IPO上市模式。“红筹”可以划分为“大红筹”(国企红筹)和“小红筹”(民企红筹)。 “小红筹”的操作模式是,境内居民设立离岸公司,然后通过并购将境内公司的资产或股权转移到离岸公司名下,境内公司变成外商独资企业或中外合资企业。红筹模式的优势在于,除国内公司的生产经营活动须遵守中国大陆法律外,离岸公司的上市程序只须遵守上市地及离岸公司注册地的法律,而不受中国大陆法律的限制。 而在上市之前,以上市为目标,以红筹模式的形式实施的私募股权投资,是很常见的PE投资架构。具体如下图所示: 三、新浪模式 “新浪模式”,是指新浪公司在2000年上市前,为了满足国内监管和公司海外上市的双重要求而设计的一套复杂的交易架构体系。依据中国《电信条例》及外商投资产业指导目录等法律规范,外资是禁止介入电信运营和电信增值服务的,而网络信息服务属于电信增值业务。也就是说,根据有关法规,要继续经营互联网业务,就不能在海外上市。另一方面,当时信息产业部的政策性指导意见是外商不能提供网络信息服务 (ICP),但是可以提供技术服务。于是在中国的特定政策下,“新浪模式”最终得以问世。 在“新浪模式”下,外国资本通过投资离岸控股公司(即特殊目的公司)来控制设在中国境内的外商独资企业(WFOE),该外商独资企业不能直接经营增值电信业务,但可以为实际经营增值电信业务的内资公司提供技术服务,外商独资企业与内资公司之间,将通过独家服务合作协议等一系列合同安排紧密地捆绑在一起。由于境外会计师认可这种合同绑定方式,特殊目的公司与内资公司之间虽然不具有股权关系,但报表却能被合并到特殊目的公司,这样,境外特殊目的公司就可以实现在海外上市。 新浪模式实际上是红筹模式的一种创新。其超越是,特殊目的公司(SPV)并没有收购内资

企业高管架构常见模式分析

企业高管架构常见模式分析 一、企业组织结构设计基本要求 1、工作专门化。把握好分工与协作的关系,把工作任务和目标具体细分。 2、部门化。将相似及相近的工作岗位归到同一部门,以实现组织的良好协作,精干高效。 3、集权与分权。合理设计集权及分权管理机制,实现责权利相一致。 4、命令链。命令链是指组织的工作信息反馈机制应指挥同一,传递通畅。 5、控制宽度。控制宽度是指合理设计每个管理者的管理幅度,使其管理能力充分发挥,一般来说,每个上级直接控制的下级宽度在6~9人之间为佳。 6、正规化。正规化是指组织结构应具有稳定性及权威性,对组织成员的工作起到纲领性的指导作用,不能轻易更改,组织结构是整个组织运转的基础。 二、组织职位权限设计基本理论 1、对于职位权限的设计,总体可分为三类:基于工作任务的工作权限;基于经济费用的经济权限;基于人事方面的人事权限。 2、关于职位权限的高低层次,可以具体划分为五级。每个层级的权限范围及主要职责如下图所示: 随时抽查、检查工作;推翻或更改既定制度、工 作或事项;进行体制改革,建立新的重大机制。 对工作或事项处理做出最终的决定性意见;对既 定的制定、工作或事项的指导、修改、指正权; 对管辖范围内的工作进行监督、审核、批准或处 理;参与对管辖范围外的工作或事项的处理。 主办工作,在规章制度范围之内选择工作方法权; 对管辖范围内的工作或下属工作的设计、改进权; 对管理范围内的事项的处理权;审核工作,并向 上级报送审批。 常规工作的拟定工作计划、拟定工作方式权;对 管辖范围内的工作或下属工作的监督权、检查权。 常规工作执行办理权;经上级领导分配后工作的 具体操办权;对工作方式、事务处理方法改变的 建议权;对非保密工作的咨询、了解、关注权。 由上图可知,在企业职位权限的层次划分中,一级、二级权限属于组织决策层次,应由企业高层管理人员掌控;三至五级权限则属于组织运作层次,应具体细分到各个部门各个岗位。

制造业企业一般组织架构

制造业企业一般组织架构 制造业企业的组织架构,尤其是电子制造业,在沿海已经发展成了一种比较成熟的模式。在这里我想谈谈它的组织结构,有兴趣的可以看看。 直接参与生产的:一般是生产部,工程部和品质部。这三个部门,生产部负责生产的具体组织,与普通员工的管理;工程部负责为生产部提供生产上的技术支持,协助解决生产中出现的问题,负责制作作业指导书,指导生产工艺;而品质部,负责从来料到生产过程中再到生产结实出成品,的质量检测,纠正生产中出现的质量问题。品质和生产,在发展的比较正常的企业,经常是一对冤家,如不如此,品质监督生产,就好象议会监督政府一样。如不如此,则产品的质量无法保障。而工程,则为生产和品质提供技术问题的解决服务,指导如何生产。 由销售部签定合同,发文给生产计划部,由生产计划部安排协调生产。货仓部接到生产计划部的生产通知,负责按时足额为生产部提供生产原料。生产部接生产计划部通知,安排生产任务的具体执行。供货商提供的原材料,经开发部测试合格,由开发部发物料确认书,由采购部负责具体的采购,财务部负责发款,日常来料质量由品质负责检测,合格后货仓部确认接受。生产过程中的半成品质量确认,生产工艺的检查,以及成品的老化测试,全由品质部负责。通常品质和生产分别由互不隶属的经理负责,如果这两部门和和气气,则质量不易保证。 产品的开发,首先由开发部和销售部确认市场需求,确定开发目标。以电子企业为例,由电子组负责电子部分的设计方案,结构组设计外框架与美工,软件组负责产品软件设计调试,这其中一般以电子组负责人任项目经理牵总头。电子结构软件共同开发出第一版,试制样品测试总结问题,改进后成第二版,再测试总结问题。直到产品可以接受,再开始产品第一次试生产,由开发部指导,生产工程品质协调,生产后总结生产出现的问题点,改进之。直到再次生产不再出现不可接受的问题。而后由开发部负责人员培训,以及下发相关技术资料,作为生产准则,工程部负责作业指导书,而后可以开始量产销售。产品的售后服务,由售后部负责,比如产品返厂维修等,同时售后部还负责向开发部生产部品质部工程部,反映产品质量问题的重要责任。 以上生产和开发方面的系统,一般公司最高决策层不抓具体管理,因为决策层不一定具有相关专业知识也没有那么多的精力。决策层应该牢牢抓住的是销售和财务。销售部负责联系客户,反映市场信息;财务部负责公司一切和资金来往的事物,包括采购材料款,销售回款,工资发放等。这两部门是公司命脉,老总抓住这两点就可以牢牢控制住公司。此外,人事行政部,具体事物也不必由公司最高决策层管理。各部门任用人员需要的是相关专业知识的人,决策层不一定有这样的知识去判别,所以各部门用人由各部门决定,人事行政部部只是负责登记等过程性事物。不过各个部门的负责人任用,则应该由最高决策层负责。而行政方面基本上都属于琐碎的事情,比如公司电脑维护食堂管理等,由其负责人自行管理即可。 决策执行与监督,都由各个不同的部门负责。生产的具体执行,由工程部和生产计划部负责决策,生产部负责执行,品质部负责监督。物料采购和产品销售,也分别由采购部和销售部决策,货仓部和生产部以及财务部执行,品质部监督。而开发流程,由市场部与开发部共同决策,开发部负责具体执行,开发出产品由生产部品质部工程部检验。确保所有权利都不会过于集中在某一部门,确保每一部门都被另一部门监督,环环相扣的系统。 附:某一公司部门列表:

几种常用软件架构设计指南

几种常用软件架构设计指南 软件架构(software architecture)是一系列相关的抽象模式,用于指导大型软件系统各个方面的设计。软件架构是一个系统的草图。软件架构描述的对象是直接构成系统的抽象组件。各个组件之间的连接则明确和相对细致地描述组件之间的通讯。在实现阶段,这些抽象组件被细化为实际的组件,比如具体某个类或者对象。在面向对象领域中,组件之间的连接通常用接口来实现。 软件体系结构的定义 虽然软件体系结构已经在软件工程领域中有着广泛的应用,但迄今为止还没有一个被大家所公认的定义。许多专家学者从不同角度和不同侧面对软件体系结构进行了刻画,较为典型的定义有: Dewayne Perry和A1ex Wo1f曾这样定义:软件体系结构是具有一定形式的结构化元素,即构件的集合,包括处理构件、数据构件和连接构件。处理构件负责对数据进行加工,数据构件是被加工的信息,连接构件把体系结构的不同部分组组合连接起来。这一定义注重区分处理构件、数据构件和连接构件,这一方法在其他的定义和方法中基本上得到保持。 Mary Shaw和David Garlan认为软件体系结构是软件设计过程中的一个层次,这一层次超越计算过程中的算法设计和数据结构设计。体系结构问题包括总体组织和全局控制、通讯协议、同步、数据存取,给设计元素分配特定功能,设计元素的组织,规模和性能,在各设计方案间进行选择等。软件体系结构处理算法与数据结构之上关于整体系统结构设计和描述方面的一些问题,如全局组织和全局控制结构、关于通讯、同步与数据存取的协议,设计构件功能定义,物理分布与合成,设计方案的选择、评估与实现等 Kruchten指出,软件体系结构有四个角度,它们从不同方面对系统进行描述:概念角度描述系统的主要构件及它们之间的关系;模块角度包含功能分解与层次结构;运行角度描述了一个系统的动态结构;代码角度描述了各种代码和库函数在开发环境中的组织。 Hayes Roth则认为软件体系结构是一个抽象的系统规范,主要包括用其行为来描述的功能构件和构件之间的相互连接、接口和关系。 David Garlan和Dewne Perry于1995年在IEEE软件工程学报上又采用如下

模型驱动的体系架构MDA

模型驱动的体系架构MDA 很多组织已经开始对模型驱动的体系架构(MDA)进行关注,MDA 是一种应用系统设计和实现的方法。对于几个原因来说这都是非常积极的发展。 MDA 鼓励在软件的开发过程中有效的使用系统的模型,并且它支持创建类似系统的最佳实践的重用。所谓由对象管理组织(OMG)定义的标准,MDA 是一种组织和管理被自动化工具支持的企业体系架构和用于定义模型和推动不同模型类型之间的转换的服务的方法。 当被 OMG 定义的 MDA 标准和用于创建和进化企业级软件系统的术语在业界被广泛的引用时,仅仅到目前为止, OMG 和它的成员,包括 IBM Rational ,已经能够在 MDA 意味着什么、MDA 将向哪里发展、MDA 的哪些方面对于今天的技术是可能的和如何在实践中利用 MDA 上提供清晰的指导。 有效的企业软件开发 今天开发企业级的应用要求一种软件架构的方法,这种方法应该能够以一种灵活的方式帮助架构师来发展他们的架构。这种方法应该允许在及时的实现业务功能的新的能力的情况下重用已有的劳动成果,甚至是当目标基础架构本身在一直的演进。两个重要的思想现在被认为是应对这种挑战的中心: ? 面向服务的体系架构(SOA)。企业解决方案能够被视作通过良好的说明定义了他们的服务接口契约连接的服务联合。结果的系统设计通常被称作面向服务的体系架构(SOAs)。通过将一个系统组织成为被封装好的服务集合,这些服务可以通过他们定义的服务接口被操作,系统的灵活性被大大的增强了。现在很多组织用一系列的服务和服务之间的相互连接表示他们的解决方案。 ? 软件的产品线。通常,在一个组织开发和维护的系统中,存在着大量的可公用的部分。从捕获核心业务过程和领域概念的标准领域模型,到开发人员在代码中使用的实现设计的实现细节方案,我们在企业的软件项目的每一个级别上看到了重用的方法。当模式能够被经验丰富的从业者开发出来并在跨越组织的范围内传播时,软件开发组织将获得大量的效率。这表现了一种朝着促进计划的资产重用,增加自动化的级别来实现被开发系统大部分的方案的软件产品线开发视图的迁移。更加普遍的情况下,我们能够将在开发的产品线视图中定义良好模式的应用理解成为一种从一个抽象级别到一个更底层抽象级别的方案转化描述的方法。 这两种思想对对象管理组织(OMG)的思想有着重大意义的影响,一个开发和支持规范以改进企业软件开发和部署实践的软件组织联盟(在下一个部分 OMG 将扮演更重要的角色)。OMG 已经创建了一个概念性的框架,这个概念性的框架将平台选择与独立的面向业务的决定分离开来以使在架构和演进这些系统时允许更大的灵活性。这个概念性框架和帮助实现它的标准就是 OMG 称为的"模型驱动的体系架构(MDA)."。应用的架构师使用 MDA 框架作为表示他们企业架构的蓝图,并且使用在 MDA 中的开发标准作为他们独立于供应商和技术的"未来的证明"。 OMG 的 MDA 的概念通过 OMG 的构建模型的标准对系统的交互性提供了一种开放的、供应商中立的方法:统一建模语言(UML),Meta-Object Facility (MOF),XML Metadata Interchange (XMI) 和Common Warehouse Meta-model (CWM) 。企业应用的描述能够使用这些建模标准被建立并被转化到一种主流的开发的或者是私有的平台上,包括 CORBA ,J2EE ,.NET 和基于 Web 的平台。 在我们开始深入的了解 MDA 之前,让我们考虑一下在软件开发中进行建模的基本概念和好处。 建模的基本原理 模型提供了一个物理系统的抽象,模型可以让工程师们通过忽略无关的细节而把注意力放到系统的重要部分来思考系统。工程中的所有工作形式都依赖模型来理解复杂的、真实世界的系统。模型被用在很多的方面:预期系统的质量,当系统的某些方面变化时推理特定的属性,和为各种涉众沟通关键的系统特征。模型也可以作为实现物理系统的先驱被开发,或者模型可以根据一个已存在的系统或者开发中的系统被产生作为理解系统行为的帮助手段。

第三方支付公司的组织结构一般模式

支付知识 第三方支付公司其组织架构有那些呢? 支付宝组织结构图 一设总裁或者总经理办公室为集团总部领导人员 总裁办公室下设行政部办公司管理日常琐碎事宜并管理所有人员的考情和出差订票等事宜 二市场部 1 分支机构管理部门管理全国分支机构用户协调全国分支机构和总部各部门的沟通 2 产品规划部用户规划全国产品和营销方案的设计 3 集团项目部用于全国的项目规划落地 4 商圈建设部实行全国的商圈建设和商户的接入 5 分支机构的省市分公司实现全国各地区的销售和后续的维护和管理 三运营部 1 客服部负责全国用户的咨询和事物的处理 2 运维技术部负责整体系统的维护 3 产品测试部负责产品的测试和上线 4 对外宣传部负责对外宣传和官方网站的建设 5 运营合作部负责配合市场做技术支撑和活动配合 四技术研发部负责产品的研发和技术服务支撑根据项目设立部门 五风险规规范部 1 风险管理部负责数据监督和风控事宜 2 金融行业部负责金融行业协调和配合市场做相关事物处理 3 清算中心组负责每日的数据核对和相关数据清算

4 合同管理部主要是法律和合同管理事宜 六财务部 摘要:第三方支付是现代金融服务业的重要组成部分,作为独立机构提供的交易支持平台。也是中国互联网经济高速发展的底层支撑力量和进一步发展的推动力。2013年,余额宝的崛起,开启了全民理财的新篇章,也让其他第三方支付公司看到了金融理财巨大的市场。 第三方支付是现代金融服务业的重要组成部分,作为独立机构提供的交易支持平台。也是中国互联网经济高速发展的底层支撑力量和进一步发展的推动力。2013年,余额宝的崛起,开启了全民理财的新篇章,也让其他第三方支付公司看到了金融理财巨大的市场。 突围策略 第三方支付命悬一线转型瞄准综合金融服务 “现在的市场环境纯做支付很难挣钱,第三方支付必须转型,布局其他业务,否则必死。”近日,一位银联内部人士告诉《每日经济新闻》记者。 记者深入支付机构调查发现,目前支付机构充当融资中介,行业里比较普遍,大型支付机构均有涉足,模式大致是支付机构向银行提供商户交易流水和信息,由银行审核后放贷。 业内人士称,支付平台连接大量的商户、用户和金融资源,并沉淀了海量交易数据。这些资源和数据对于展开综合金融服务极为有利。 同时,与“余额宝”类似的金融理财服务方面,支付机构过去一年也都迈出了第一步,余额理财成为支付机构的又一增值服务。面对火热的P2P领域,支付机构则以平台资金托管为主,有个别平台也建立了内部的P2P平台。

企业如何选择五种组织架构模式

企业如何选择五种组织架构模式? 关于企业的组织架构模式,德鲁克提出了五种组织架构的模式。虽然后来有很多人把他提出来的组织架构模式称为什么网状模式,甚至叫什么燕子形模式,但是这些模式基本上都分属于德鲁克提出的五种组织架构模式中的某一种。我在《德鲁克谈企业管理》一书中,对于这五种模式的优劣有所比较。 第一种组织架构模式是功能式的组织架构。对于企业来说,功能就是指供、产、销和人、财、物,企业是以这些功能作为导向来设置组织的。也就是说,绝大部分企业的组织架构是金字塔式的格局。比如,大部分企业都设有财务部门、生产部门、人事部门(人力资源部门),还有所谓的研发部门等。大多数的企业都有这些部门,但是这些企业是否有效率呢?不一定,因为功能式架构的企业存在着一个最大的问题是企业没有办法对外界的变化做出快速而有效的反应,所以往往就会出现这样的情况,企业内部不断地沟通、协调、再协调,这些都要花费大量的时间。在功能式组织架构的企业里,要做出一个重大的决策往往需要花费大量的时间,即使这样还不一定能够做好,所以,很多人发现,功能式的组织架构好像没法对外界的需求做出有效的反应。 第二种组织架构模式是工作小组模式。就是企业的组织不是固定的,而是以项目为导向的。如果企业有一个项目,企业中的人员就会被调动到这个项目上,组成一个工作小组,这就叫工作小组模式。一个小组里可能有5个人,或者10个人,这是不确定的。比如说,以董事会为例,不管是有5个人,还是有7个人,这都叫做工作小组。工作小组是因为任务而存在的,是以任务为导向的。 第三种组织架构模式是联邦式的组织架构。现在绝大多数的大企业基本上都采用这种组织架构模式。联邦式的组织架构就是把企业里所有的事业群统统分开,把权力充分下放,因为企业总部和事业群之间的关系就好像联邦政府中的中央跟地方的关系一样,所以称之为联邦式的组织架构。联邦式的组织架构的关键不在于分权,关键是让事业群能够良好运作,所以说,可以不叫“分权”,因为用分权的概念好像是把组织上层的权力分到下面去了,那组织的高层就会说:“我干吗要把权力分下去?”事实上不是这样的。事实上是通过“授权”,让企业中的每一个部门,尤其是事业群能够发挥各自的作用,能够独立运作、发挥功能,这才是最关键的。 第四种组织架构模式是虚拟的分权化的组织架构。采用这种组织架构的企业,从表面上看起来像是联邦式的组织架构,但事实上每一家独立的事业群就好比是一家独立的公司,需要负责自己的盈亏。企业会通过对事业群设定目标来管理事业群。采用这种组织架构的企业,其主要的目的是要让虚拟的分权得以控制。绝大多数的跨国公司的组织架构是这种类型。 最后一种组织架构模式是系统结构模式。NASA(美国宇航局)采用的就是这种模式。NASA有几十个、几百个不同的关联单位,因为NASA要和很多的相关部门发生联系,像气象、电机、电子部门等。比如说,是今天发射还是明天发射,是上午发射还是下午发射,这是一定要气象部门去做判断的。将这些相关的部门和单位统统集合起来,才是系统结构的组织架构模式。而这个模式的最大的妙处还在于它能够使得各个部门或组织之间保持良好的沟通,这是这种组织架构模式的最大特色。 企业应该如何选择一种组织架构模式呢?因为它们各有各的优点,各有各的限制,也

相关文档