OMG编译器
❶ c语言在64位系统上怎样编辑运行
C语言源程序的编译及运行的关键是在于编译器而不是系统平台。
在64位系统下，如果使用能够兼容32位的编译器，那么编译的程序就是32位的。当然，对于大多数32位编译器，都不能很好的在64位系统下运行。这个时候你就需要一个64位的编译器，比如微软的Visual C++ 2010及以上版本，下载的时候注意下载x64版本。使用64位编译器编译出来的程序就是64位的。
使用64位平台编译程序的时候需要注意一个问题：
int相关的类型在不同位数机器的平台下长度不同。C99标准并不规定具体数据类型的长度大小，只规定级别。作下比较
（1）16位平台
char 1个字节8位
short 2个字节16位
int 2个字节16位
long 4个字节32位
指针 2个字节
（2）32位平台
char 1个字节8位
short 2个字节16位
int 4个字节32位
long 4个字节
long long 8个字节
指针 4个字节
（3）64位平台
char 1个字节
short 2个字节
int 4个字节
long 8个字节（区别）
long long 8个字节
指针 8个字节（区别）
❷ java如何调用c语言源文件并进行执行.
Think in java 这本书的附录有这么一章 使用非JAVA代码
附录A 使用非JAVA代码
JAVA语言及其标准API（应用程序编程接口）应付应用程序的编写已绰绰有余。但在某些情况下，还是必须使用非JAVA编码。例如，我们有时要访问操作系统的专用特性，与特殊的硬件设备打交道，重复使用现有的非Java接口，或者要使用“对时间敏感”的代码段，等等。与非Java代码的沟通要求获得编译器和“虚拟机”的专门支持，并需附加的工具将Java代码映射成非Java代码（也有一个简单方法：在第15章的“一个Web应用”小节中，有个例子解释了如何利用标准输入输出同非Java代码连接）。目前，不同的开发商为我们提供了不同的方案：Java 1.1有“Java固有接口”（Java Native Interface，JNI），网景提出了自己的“Java运行期接口”（Java Runtime Interface）计划，而微软提供了J/Direct、“本源接口”（Raw Native Interface，RNI）以及Java/COM集成方案。
各开发商在这个问题上所持的不同态度对程序员是非常不利的。若Java应用必须调用固有方法，则程序员或许要实现固有方法的不同版本——具体由应用程序运行的平台决定。程序员也许实际需要不同版本的Java代码，以及不同的Java虚拟机。
另一个方案是CORBA（通用对象请求代理结构），这是由OMG（对象管理组，一家非赢利性的公司协会）开发的一种集成技术。CORBA并非任何语言的一部分，只是实现通用通信总线及服务的一种规范。利用它可在由不同语言实现的对象之间实现“相互操作”的能力。这种通信总线的名字叫作ORB（对象请求代理），是由其他开发商实现的一种产品，但并不属于Java语言规范的一部分。
本附录将对JNI，J/DIRECT，RNI，JAVA/COM集成和CORBA进行概述。但不会作更深层次的探讨，甚至有时还假定读者已对相关的概念和技术有了一定程度的认识。但到最后，大家应该能够自行比较不同的方法，并根据自己要解决的问题挑选出最恰当的一种。
A.1 Java固有接口
JNI是一种包容极广的编程接口，允许我们从Java应用程序里调用固有方法。它是在Java 1.1里新增的，维持着与Java 1.0的相应特性——“固有方法接口”（NMI）——某种程度的兼容。NMI设计上一些特点使其未获所有虚拟机的支持。考虑到这个原因，Java语言将来的版本可能不再提供对NMI的支持，这儿也不准备讨论它。
目前，JNI只能与用C或C++写成的固有方法打交道。利用JNI，我们的固有方法可以：
■创建、检查及更新Java对象（包括数组和字串）
■调用Java方法
■俘获和丢弃“异常”
■装载类并获取类信息
■进行运行期类型检查
所以，原来在Java中能对类及对象做的几乎所有事情在固有方法中同样可以做到。
A.1.1 调用固有方法
我们先从一个简单的例子开始：一个Java程序调用固有方法，后者再调用Win32的API函数MessageBox()，显示出一个图形化的文本框。这个例子稍后也会与J/Direct一志使用。若您的平台不是Win32，只需将包含了下述内容的C头：
#include <windows.h>
替换成：
#include <stdio.h>
并将对MessageBox()的调用换成调用printf()即可。
第一步是写出对固有方法及它的自变量进行声明的Java代码：
class ShowMsgBox {
public static void main(String [] args) {
ShowMsgBox app = new ShowMsgBox();
app.ShowMessage("Generated with JNI");
}
private native void ShowMessage(String msg);
static {
System.loadLibrary("MsgImpl");
}
}
在固有方法声明的后面，跟随有一个static代码块，它会调用System.loadLibrary()（可在任何时候调用它，但这样做更恰当）System.loadLibrary()将一个DLL载入内存，并建立同它的链接。DLL必须位于您的系统路径，或者在包含了Java类文件的目录中。根据具体的平台，JVM会自动添加适当的文件扩展名。
❸ 如何基于visual studio 进行数据建模
Visual Studio Team System 建模策略与 FAQ
适用于：
Microsoft Visual Studio Team System
摘要：客户和合作伙伴迫切希望了解 Microsoft 对于模型驱动开发的策略，及拍芦其对 Visual Studio Team System 的支持。当向他们解释我们的策略时，他们经常表现出对某些相同主题的兴趣，并引出一些相同的关注点。本文，我们讲述模型驱动开发的策略，以及开发人员通常会涉及到的一系列问题与解答。首先的五个问题涉及到我们策略的主要结构，我们将对其进行详细的回答与解释。其他的常见问题均集中于最后一部分的常规 FAQ 部分中。
本页内容
为什么建模？
如何在模型驱动的开发中使用 DSL？
UML 如何？
MDA 如何？
软件工厂是什么？
其他常见问题
为什么建模？
客户曾经告诉我们，他们在 80 年代和 90 年代初所购买的多数 CASE 工具不能为开发过程增加足够的价值。由购买的工具带来的利益并未实现，甚至好的产品也会被过度夸耀的技术承诺所掩盖。
如果工具支持的模型不能反应代码以及其他的实现产品，那么这些工具很快就会被摒弃。如果工具支持的模型用于生成代码，那么当开发人员根据生成的代码增添其他代码时，工具通常不能与之同步。尽管这些工具为生成的代码提供了很好的"往返行程"，但最终开发人员还是身陷于解决此类问题的错综复杂的情况中。因为 CASE 工具试图以超高级别的抽象（与底层实现平台相对）进行操作，所以这些问题经常变得更糟。这会导致生成大量代码，由于混合了手写代码和生成的代码，因此要解决这些问题更加困难。
尽管存在这些问题，但是与某些软件开发过程有关的一个观点是 - 应用建模可以让开发更轻松。我们的目标是改变开发人员看待建模价值的方式。要将他们的观点（建模是一个在真正开始开发之前不太重要的有用活动）改变为承认建模是一个重漏贺友要的、主要的开发任务，并且不是主要集中于文档的活动。当将模型视为首要的开发产品时，由于可以使用更强大的应用程序抽象，因此开发人员会编写更少的常规代码。模型驱动的开发也因此顺理成章地更加高效和灵活。此外，其他涉及到的开发人员（从业务分析师、架构师、设计师到网络的用户以及系统管理专业人员）会发现建模对其所负责的任务会产生增值。当模型以这种方式横跨开发和运行时活动时，人员之间的交流可以得到优化，且可跟踪性使得能够跨越生命周期的任何阶段。我们坚信，以这种方式确立建模的主要位置，最终可以改变软件开发的经济性，并且保证软件系统能够满足业务的需要。该模型驱动开发的方法由 Microsoft 首创，是名为软件工厂 的产品的一部分。
注 软件工厂的深入说明，请参阅“Software Factories: Assembling Applications with Patterns, Models, Frameworks and Tools”，作者为 Jack Greenfield 和 Keith Short，以及 Steve Cook 和 Stuart Kent。
返回页首
如何在模型驱动的开发中使用 DSL？
Microsoft 已经从过去的行业经验中有所收获，并且避免了 CASE 的缺陷，这是通过采纳基于返槐下列想法的模型驱动开发实现的：
模型应该是项目中首要的产品 - 不仅仅是一些快过时的文档。模型有精确的语法，通常利用图形化工具易于进行编辑和浏览，并且包含确定模型中特定于域的概念如何映射到其他实现产品的语义，这些实现产品包括代码、项目结构和配置文件等。按照这种方法，模型非常类似于源代码文件，而且它与其他实现产品同步的机制非常类似于编译器。
模型表示一组抽象，它以定义完善的开发内容为开发人员提供支持。例如，考虑这样一个任务：生成一个通过 Web 服务与组件进行连接的、面向服务的应用程序。要构建这样一个应用程序，假设给定开发人员必须关注的所有其他任务，在这种情况下，根据服务合同和开发人员之间交流的信息，该开发人员可以只关注定义整个应用程序连接性。为软件架构师的应用程序设计器提供的 Visual Studio Team Edition 完全支持开发的个各个方面，并管理应用程序连接性模型和所有其他产品（WSDL 文件、项目文件、代码文件、配置文件等）之间的关系。必须开发这些产品以实现由模型定义的互联。按照这种方式设计作为源产品的模型，具有额外的好处 - 提供对其他分散细节的整体视角，并且能够让不同团队（包括设计、构建和部署复杂、现代化应用程序）之间的沟通更加顺畅。
由于模型能够提炼并聚合大量产品中的信息，因此它们能够更轻松地支持一致性检查和其他形式的分析。例如，一个应用程序连接模型可以支持协定协议验证、安全性分析或性能分析。
通过一个与编辑类似的过程可以实现模型，在该过程中，由编译器生成的代码、配置文件和其他实现产品均不能进行手工编辑。然而，较普遍的情况是，模型可以由生成产品和手工编辑产品的组合实现。在这种情况下，非常重要的一点是，仔细管理使生成和手工编辑产品相互适应的方法。如上所述，不能有效做到这一点是 CASE 产品的一个主要不足之处。我们已经使用了一些技术来确保生成的产品和手工编辑产品保持独立，并且当生成工具需要套用代码时，决不会与由开发人员添加的代码发生冲突。这些技术包括，使用类委托和继承，特别是使用"部分类" - 它是 Visual Studio 中 .NET 语言的一个新特性，利用成形的任务已经进行了特别定义。
我们将以这些方式定义的建模语言称为 Domain Specific Languages 或 DSL。可以将 DSL 想象为一种用来解决一些清晰确认问题的小规模、高集中化的语言。这里所说的问题是分析师、架构师、开发人员、测试人员或系统管理员必须要处理的问题。开发人员已经熟知的 DSL 示例是：用于数据操作的 SQL 和用于 XML 文档结构定义的 XSD，等等。另一个来自 Visual Studio Team Edition for Software Architects 的示例是，用于对数据中心硬件和宿主软件配置的逻辑结构进行建模的 DSL。该 DSL 及其相关的图形设计器可以用于设计时（配置应用程序以与其部署目标相匹配）的验证，在问题可以更容易地解决时向开发人员发出警告。
找到备选 DSL 的好办法是明确开发人员使用的模式，然后将其封装到建模语言中，或将软件框架中的概念作为建模语言中的抽象表层化，然后能够生成可扩展整个框架的少量代码。这些技术允许我们控制生成代码的数量和复杂度，从而为开发人员提供真正意义的价值，而无需争论对 CASE 产品的刻画。
最近，Microsoft 发布了 DSL 工具 - 使客户和合作伙伴能够通过 Visual Studio 中的相同的技术构建 DSL，这些技术用于构建与 Visual Studio Team Edition for Software Architects 一起发行的建模工具。可以将该技术认为是"构建工具的工具"，简化了定义 DSL 的任务，并降低了为工具构建图形化编辑器和编译器的代价和技能
返回页首
UML 如何？
多数理解我们就模型驱动开发这一观点的人员，把我们假想为将重点放在 DSL 上，这一假设将我们置于一个与 UML 对立的位置。我们希望对这一不正确的想法予以澄清。在 UML 之前，各种各样的建模方法缺乏生产效益，这些方法最终形成 UML 1.0，这是在软件开发中使用模型方面向前迈进的重要一步。
但是不管是出于什么原因，UML 和基于 UML 工具的存在没有显着改变开发人员构建应用程序的方式。或者说，没有为开发人员生产效率提供明显的帮助。自从 Microsoft 提供了一个最可用的 UML 工具（基于 Visio 的工具）- 最先与 Visual Studio Enterprise Architect 一起提供，我们对该工具的使用进行了开发人员的（不仅限于我们的客户）匿名调查。我们发现，只有很少数人声明其任务支持 UML 工具，大部分使用者仅使用类图表。当我们训练这部分声明使用类图表的人员时，实际使用它们生成代码的数量很少。
除了在 Visual Studio Team Edition for Software Architects 中的模型驱动的开发工具之外，这是驱动因素之一。我们真正想要进行的是开发人员和架构师很难发现的任务，并找出建模工具可能为其增值并提供帮助的办法。我们强烈支持 UML 符号和图表。在 Microsoft 中任意的开发人员办公地点走走，就会发现白板上密布着 UML 类图表以及序列图表。我们不仅在规范文档中、在很多其他为演示准备的图表中使用 UML 符号，甚至还会将 UML 符号记录在自助餐厅的餐巾纸上。要支持客户的这些需要以生成文档和概念化草图，我们将继续在 Visual Studio 中提供 UML 工具集。事实上，通常在 Microsoft 内，我们使用 UML 的目的很多（例如用于文档或概念共享），但几乎从未 有任何一个是出于以下目的，这些文档是软件开发的实际产物。
办公室和走廊里相同的白板也布满了随意写下的代码。但在这里再次声明这都是草稿。这些代码很少能正确指示程序源代码编译。这对开发人员而言是重大的区别。任意一种有助于实际软件开发的产品必须能够进行数字化操作。源代码有定义完善的语法，易于理解的语义（通常由编译器的转换以较低级的代码或中间语言定义），并且能够由编译器、调试器和重构程序进行一致性操作。要有益于开发人员，模型必须 有与源代码相同的状态。模型还必须有精确的语法、易于理解的语义，以及定义完善的到源代码或其他定义完善模型的映射。它必须不仅 限于文档。
例如，采用 Visual Studio Team Edition for Software Architects' Application Designer。它不仅仅是文档，虽然它以该目的进行使用。它更希望使开发人员（或架构师）能够将注意力集中于系统的某一部分；而不是面向服务的体系结构中服务间的连接。她可以在构建项目、WSDL 文件、代码和架构之前设计系统的该部分，或要求工具文档化服务间的连接（如果这些产品已经存在）。由于连接信息分散于众多开发产品之中，因此整体视图（如图表）提供了基本的使用，尽管所有传递的信息可能因对实施产品的仔细检查而减少。应用程序设计器有定义完善的语法（它的 DSL 元模型）和可预知的、始终同步的到各种实施产品的映射。基础设计器框架承担应用程序设计器图表编译器的作用，非常类似于与源代码文件相关的传统编译器的作用。
但是，为什么我们不能只将这种新的服务连接"语言"构建为对 UML 的扩展呢？特别是对 UML 2.0 的改进呢？
当然，当我们看出采取 UML 2.0 规范的趋势时，我们意识到，它依旧不能成为文档之外其他事物的基础是有原因的。由于更加复杂的子语言，UML 2.0 规范已经增加了标准的复杂性，但是它依旧不能以一种自然的方式解决现代应用程序开发的关键问题，例如，数据库设计、测试、部署、面向服务、基于组件的开发以及用户界面结构。由于没有自然的 UML 子语言满足服务连接的需求，因此我们必须利用现有 UML 子语言中的构造型和标记来重新描述我们的应用程序设计 DSL。这会导致在已由业界众多膨胀、复杂的规范描述的设计中极其复杂的模型。利用标准的 UML 符号（其中，对应于任何已经扩展的子语言中现有的形状都可以重用），对于图表的可读性和清晰度而言是一种折中方案。最后，我们会纠缠于规范中关键内容缺乏精确度以及 UML 中固有的类型系统不匹配（较之于 .Net 和 XML 语言）之中。
由于这些原因，我们选择利用一个为特定目的构建的元模型来定义应用程序设计 DSL，该模型本身作为相关元模型家族中的一员进行定义。这为服务连接提供了自然且精确的基础，以及到基础实施产品（当然包括一些代码）的高保真映射。对于其他关注的开发任务，我们已经得到了相同的结论，并因此产生了与其他白皮书中所述相似的类设计器和逻辑数据中心设计器的 DSL。对可扩展 DSL 的支持，构建为一系列具有定义完善的 DSL 与其他开发产品间的映射，最终成为 Microsoft 模型驱动开发策略的基础。
综上所述，我们推荐在以下情况下使用 UML 和基于 UML 的工具：
草图。
白板。
餐巾纸。
文档。
不直接与代码相关的概念性绘图。
我们推荐在以下情况中使用恰当定义的 DSL 和基于 DSL 的工具：
从中生成代码的精确抽象。
映射到框架和组件中变化点的精确抽象。
DSL 之间的精确映射。
具有到其他 DSL 或代码产品的精确指明映射的概念性绘图。
我们不推荐将上述几点用于详细编程逻辑的可视化编程（或至少在近几年之内）。
返回页首
MDA 如何？
MDA 是 OMG 的一个授权品牌，它基于利用模型驱动开发的 UML。它重点强调与平台无关的模型以及衍生出的技术。根据 OMG FAQ，
"MDA 是编写规范和开发应用程序的一种新方式，它基于平台无关的模型 (PIM)。完整的 MDA 规范包括，一个基于 UML 模型的确定无关平台、一个或更多特定于平台的模型 (PSM) 以及接口定义集，它们分别描述基本模型如何在不同的中间件平台上实现。完整的 MDA 应用程序包括，一个确定的 PIM、一个或更多的 PSM 以及完整的实施，应用程序开发人员决定支持的每个平台均对应一个 PSM。"
MDA 由 OMG 定义，仅解决实际问题的一个小子集，这些问题必须用于驱动有效的模型驱动的开发。一个有效的模型驱动开发方法必须能够解决编程问题，例如：
可以开发哪些类型的系统？由于不同系统之间存在着明显的差异，因此模型驱动开发方法必须能够辨别这些差异。要有效实现，首先描述要解决的问题，然后标识可以解决问题的特定技术，显示适合解决方案的每一种技术，各种技术如何协调工作以完成解决方案。
给定类型系统的体系结构是什么？这个问题的答案不仅仅是考虑可以使用的技术，而且还涉及识别这些技术的特性（对设计系统的每个部分都很重要），以及配置每种技术的用法。这是软件体系结构的主题，已被公认为软件生命周期中最重要的定律之一。软件体系结构定义了为系统提供其结构以及定义其质量属性的高级设计决策。由于模型最初用于描述系统重要部件的体系结构，因此模型应该更紧密地与软件体系结构开发相集成。
需要为给定类型的系统继续哪方面的建模？由于不同系统的体系结构有非常大的差异 ，因此没有单独的模型集能够有效描述所有可能的系统。因此，这个问题的答案将因系统类型而异。我们的观点是：每个目标平台上单个的 PIM 和单个的 PSM，所有的开发均利用一个由 MDA 指定的常规目的建模语言，足以支持由模型驱动开发承诺的非常高级别的自动化。软件生命周期中丰富的自动化需要大量其他类型的模型，例如以下这些模型：
捕获、分析和管理需求；标识需求之间的跟踪关系，体系结构设计和实现结构，能够进行需求已实施的验证，以及在需求变更时支持对产生影响的分析。
以下列方式定义软件体系结构：支持安全性、性能和可靠性分析以及其他格式的评估；能够从组件启用预知的系统程序集，以及有效、可逆地逐步从需求和部署进行转换。
定义可执行的系统组件如何打包，标识部署环境中每个组件都需要的资源类型，以及将组件绑定到这些资源类型的特定实例。
定义测试用例、测试数据集、测试工具和其他产品，更易于评估利用模型开发的软件的质量，以管理和显示测试结果。
标识模型和其他产品间的跟踪关系，更易于在系统宕机时支持对业务影响的分析，将系统配置为满足需求，并加强系统配置期间的约束。
定义用于构建可执行文件的源产品的配置，更易于版本化这些配置，以与缺陷报告和具有特定版本的特性变更需求相关联。
模型驱动的技术如何与代码为主的开发技术集成？模型用于辅助开发人员实现任务，例如查询和导航代码基、调试、分析、覆盖分析、模式化应用程序和重构，并且可以紧密集成到面向文件的开发环境。
此外，除了上述说明的原因，强调利用发布的 UML 元模型是我们的问题所在。最后，尽管强调平台无关是某些客户所关注的，但是我们了解到更多的是他们有关对生产率、可预见性、安全性、管理以及部署和管理应用程序的有效方式的需求。然而，我们绝对赞同有关构建应用程序而使用的模型是 MDA 的中心，且重要的是模型间定义完善的映射，我们识别以下值，模型可为其提供构建跨具有互操作组件的平台的应用程序。
某些进行模型驱动开发的组织接受对术语 MDA 更广泛的解释，而不是由 OMG 描述的解释；的确，如我们所述，他们必须这样做才能获得成功。使用任意的 OMG 规范以实现模型驱动的开发，是 MDA 典型的应用，无论是否包含 PIM 和 PSM。例如，某些组织发现 OMG 的 MOF 规范是 MDA 的关键。该观点取决于用 MOF 定义的新的建模语言，而不是在 UML 中预定义的建模语言，且该观点与我们的方法极其相似。我们将支持与其他平台上普遍采用的 UML 和 MOF 工具进行交互，通过 XMI 或是通过本机格式，帮助客户成功利用它们进行模型驱动的开发。
返回页首
软件工厂是什么？
正如前面提到的，我们对于模型驱动开发的方法是 Microsoft 称之为软件工厂 的一部分。取代了一般的、一种规模满足所有需要的方法，软件工厂使用自定义的 DSL 集合，从而提供自定义的抽象集以满足系统（例如，电子商务、金融交易或国内银行应用程序）特定领域的需要。有了软件工厂，模型不仅可以用于分析和设计，而且还支持跨越整个软件生命周期（甚至是运行时）的各种类型的计算。这是软件工厂的基本原则，并且还是 Microsoft 的 Dynamic Systems Initiative (DSI) 的基本原则。DSI 实现并完成软件工厂计划。
您可以将软件工厂认为是包含并扩展 MDA，这里对 MDA 的定义比基于 PIM 和 PSM 的正式定义范围更广泛。软件工厂超越了一般的平台独立性，并且特定的模型可解决前面部分中说明的其他问题。
利用图形化观点，软件工厂为特定的系统定义专门的方法。每个观点都为系统范围内的成员定义生命周期的某部分，例如需求获取、数据库设计或服务协定定义。工厂与每个观点的可再次使用部分相关联，并在对系统家族范围内团队开发成员观点的上下文中传递它们，这样就不需要搜索应用程序部分，能够启动验证并支持手工和自动指导设置。
观点图被称为软件工厂架构，与在一层抽象（系统的一部分）上完成的工作相关，或在生命周期的一个阶段内，在其他层（或其他部分和阶段）上完成的工作相关。观点图可用于从其他产品（特别是从模型）完全或部分生成产品（包括模型、源代码、配置文件等）；在开发阶段保持产品同步；验证手工开发的产品；评估需求失败或变更后的影响；组织并应用模式及其他最佳实践；捕获系统开发期间的元数据以支持系统操作和维护；提供其他形式的指导和管理。
软件工厂自动化可再次使用部分的打包和交付，可再次使用部分包括，模型和模型驱动的工具、其他类型工具（例如，向导、模板和实用程序）、开发过程、实施组件（例如，类库、框架和服务）以及内容部分（例如，模式、样式表、帮助文件、配置文件和文档）。由于软件工厂架构是一个模型，因此可以通过工具来操作软件工厂。创建规模较大的软件工厂，可通过合并较小的工厂以及通过自定义一般的工厂实现工厂的特殊化。
构建软件工厂与构建架构很类似。包括要使工厂更易于开发人员应用的获取和实现模式以及其他最佳实践。与通过手工从头开始构建系统相比，使用工厂更有效，这是因为使用工厂不扫描希望找到可重用组件的目录和存储库，在系统体系结构和开发过程的上下文中立即可用的开发下，使用工厂的开发人员具有可重用的组件适用于系统的各个部分。
当然，软件工厂计划不仅仅局限于 Microsoft 和我们提供的产品。相反，我们将软件工厂作为客户和合作伙伴这一广泛群体的基础，在我们提供的基础之上构建自定义的工厂，并且将工厂组件提供给这一群体中的其他成员。
客户和合作伙伴对软件工厂计划的响应是很积极的。我们建议，将软件工厂作为现代化组织的最佳发展方向，希望改善其与业务期望一致的开发方法，并且我们提供了 Visual Studio Team Edition for Software Architects、DSL 工具和 VSTS 中其他的新功能，作为软件工厂计划的首选产品。
❹ 几种开源工作流引擎的简单比较
支持的流程建模标准
WS-BPEL 2.0，流程定义必须使用该标准编写才能执行
WfMC和OMG标准
符合WfMC规范
遵循WfMC所定义的规范代码量76K548K214K不好的评价
体系和功能最为复杂，可改造性差
Shark2.0以后有很多组件不开源了
Xpdl保存在打字段中，难于分析和扩展
过于简单，只适合研究分析工作流使用
不支持工作流实例的持久化，缺少图形编辑环境，尚未全部完成WfMC定义的五类接口文档少文档
文档较为齐全
文档较为齐全
文档较为齐全文档少支持的外部接口标准
支持BPEL、Xforms、WebServiceXPDLWeb Services
包括接口1（XPDL）、接口2/3（WAPI）和4 Wf-XML接口5 Audit
自己的主观评价
框架比较灵活。ODE BPEL编译器、ODE BPEL运行时、ODE数据访问对象（DAOs）、ODE集成层（ILs）和用户工具之间耦合度低比较复杂
开发周期短的情况下不建议使用
内核非常小巧的工作流引擎，基于PetriNet模型，便于理论分析，支持持久化
有流程设计器
提供了可视化的流程编辑器
没有提供流程设计器
提供了可视化的流程编辑器开发语言JavaJavaJavaJavaJava
❺ 如何在c++定义一个学生类以实现平均成绩的计算和查询功能
一．中间件的定义与作用
1.什么是中间件？
图片摘自公众号“筋斗云与自动驾驶”
笔者在交流中发现，不同的人对中间件的理解并不一样，甚至可以说，到现在，这个概念还是模糊不清的。比如：
（1）有的人认为中间件仅指位于OS内核之上、功能软件之下的那部分组件，为上层提供进程管理、升级管理等服务；而有的人则认为中间件还应包括功能软件和应用软件中间的那部分（参见上图）。按茅海燕的说法，前者是“通用中间件”，而后者是“专用中间件”。本文中提到的“中间件”，若不做专门说明，便特指“通用中间件”。
（2）有一些人提到的自动驾驶中间件，包括了AUTOSAR（又分为AUTOSAR CP和AUTOSAR AP），还有一些人口中的中间件，特指ROS2、Cyber RT、DDS等。
（3）未动科技VP萧猛认为，“中间”一词是相对的，当有多层堆叠的时候，每一层都是其上下两层的中间层，因此，在用“中间件”这个词的时候，我们需要特别指明它究竟位于“哪两层之间”。按萧猛的说法，当我们称“ROS/ROS2 为中间件”时，其含义与 “AUTOSAR AP为中间件”并不是对等的关系。
(4)Vector产品专家蔡守群说，他理解的中间件，“是给App开发提供功能支撑的，对外是没有功能表征的；但是站在操作系统内核的角度，中间件跟App并没有本质的区别”。
2.中间件的作用
汪浩伟说：“专用中间件原本是应用程序的一部分，只是很多公司做自动驾驶都需要用到，就被抽象出来了。”
那么，它究竟有什么用？
毕晓鹏认为，自动驾驶中间件最主要的作用是：对下，它能够去适配不同的OS内核和架构；对上，它能够提供一个统一的标准接口，负责各类应用软件模块之间的通信以及对底层系统资源的调度。
据毕晓鹏解释，前者，使开发者们无需考虑底层的OS内核是什么，也无需考虑硬件环境是什么，即不仅实现了应用软件与OS的解耦，也实现了应用软件与硬件的解耦；而后者则确保了数据能够安全实时地传输、资源进行合理的调度。
为什么要通过中间件来支持软硬件解耦？毕晓鹏解释道：
我开发一个应用软件，其中很多内容都是与具体应用逻辑无关的，包括数据通信、通信安全、系统资源调度等，比如，有十个进程需要数据交互，完全没有必要在十个程序的软件代码里各自进行实现和配置。针对这种情况，我们就可以把重复的部分抽象成一种服务，单独封成一层东西（这就是中间件），并提供统一的库、接口和配置方法，供上层去调用。这样的话，有一部分人专门去做中间件的，而做上层应用的人也不需要考虑跟底层交互的事情。
举例说，如果要做一个自动泊车系统，它有各个模块或业务逻辑独立的不同软件，在进行通信、数据交互，或者调用底层资源时，只需要中间件的一个接口就可以实现，其他事情不需要考虑，这样开发人员就可以专注于自己的业务逻辑。
又比如，一个摄像头需要感知前面的车道线、红绿灯等，开发人员就专门做红绿灯和车道线检测算法，与外界的数据交互只需要使用中间件的通信服务（例如订阅摄像头信息，发布检测结果），而不必关心数据从哪里来、发给谁。
Nullmax纽劢科技系统平台总监苗干坤博士在此前的一篇文章中写道：
“芯片算力大幅增长，摄像头像素呈翻倍之势，激光雷达出现在更多新车规划上……没有谁能够断言车上的传感器应该有多少，又或者是将来的汽车还会增加哪些硬件，但所有人都知道硬件的变化将会来得更加猛烈。
“所以我们也可以看到，汽车对软硬件架构的要求也越来越高，既要能满足当下的需求，还要具备相当的前瞻性、兼容性和扩展性，能够支持接下来软硬件升级换代、增减模块的需求。而自动驾驶的中间件，就正是这样一个可以按需调整、满足各样需求的现代温室。
“在早期开发中，中间件可以化整为零，将巨大的软件工程分解成若干小任务，分散解决。在后期应用时，它又可以化零为整，像拼积木一样，根据需求将一个个模块组合成一个整体，严丝合缝。”
在春节前的一场直播中，东软睿驰产品销售总监安志鹏说，在软硬件解耦、模块化管理后，再遇到问题，就不用整个系统都改，只改相对应的部分就行了。这样，软件的可复用程度就极大地提升了，同时，验证的工作量也会减少许多，整体开发效率也会因此提升。
相反，没有中间件的话，应用层就得直接调用操作系统的接口，后期要是换了操作系统，应用层的代码和算法可能就要推倒重来。
简言之，中间件通过对计算平台、传感器等资源进行抽象，对算法、子系统、功能采取模块化的管理，并提供统一接口，让开发人员能够专注于各自业务层面的开发，无需了解无关细节。
按东软睿驰产品销售总监安志鹏的说法，搞AUTSOAR这样的中间件，并不是只对OEM有利，“零部件供应商的选择面也大了——应用做好了，下面的软件、芯片可以选好几家供应商的，要比传统的开发模式快很多，因而，零部件供应商也是受益者”。
用萧猛的话说，中间件最直接的好处就是“为上层屏蔽底层的复杂性”，软件开发人员可以忽略芯片、传感器等硬件的差异，从而高效、灵活地将上层应用及功能算法在不同平台上实现、迭代、移植。萧猛认为，中间件可以看做是自动驾驶应用背景下的一项“新基建”。
（图片摘自冯占军博士的《AUTOSAR对基础软件开发是喜还是忧？》一文。AUTOSAR只是中间件的一种，但这里写的“AUTOSAR开发优势”基本也适用于其他中间件。）
不过，站在开发者的角度看，中间件的意义也未必全部是正面的。如冯占军博士在《AUTOSAR对基础软件开发是喜还是忧？》一文中就提到了如下两点：
底层软件工程师变成了工具人，“只要你去点点鼠标，用工具配合就可以了”，很多原本由自己做的测试也改由供应商来做，进而导致工程师的成就感严重降低；时间久了，工程师从0到1开发的能力也会降低。
（图片摘自冯占军博士的文章。尽管文章说的是Autosar,但实际上这些问题在ROS等其他中间件的使用过程中也会存在。）
对软件工程师来说，中间件造成的“能力退化”这一问题几乎是无解的。但冯占军博士认为，“如果这个中间件在开发过程中，有使用公司的工程师深度参与，提出需求并一起实施，会好一些”。
此外，殷玮在一篇文章提到，使用AUTOSAR这样的中间件，Tier 1们应该是很不情愿的，“因为不到增加了成本，还有可能逐步沦为硬件生产商”。但这个也不能说是中间件的锅，在软件定义汽车大大趋势下，这几乎是必然的。
二．常见的基本概念
1. AUTOSAR CP 与 AUTOSAR AP
在所有的中间件方案中，最着名的非AUTOSAR莫属了。
严格地说，AUTOSAR并非特指由某一家软件公司开发出来的某款操作系统或中间件产品，而是由全球的主要汽车生产厂商、零部件供应商、软硬件和电子工业等企业共同制定的汽车开放式系统架构标准。不过，在实践中，各公司基于AUTOSAR标准开发出来的中间件也被被称为“AUTOSAR”。
当前，AUTOSAR可分为Classic Platform和Adaptive Platform两个平台，两者分别被简称为AUTOSAR CP与AUTOSAR AP。
简单地说，AUTOSAR CP主要跑在8bit、16bit、32bit的MCU上，对应传统的车身控制、底盘控制、动力系统等功能，如果涉及到自动驾驶的话，AUTOSAR CP可能无法实现；而AUTOSAR AP主要跑在64bit以上的高性能MPU/SOC上，对应自动驾驶的高性能电子系统。
严格地说，AUTOSAR CP并不只是个“中间件”，它是相当于“OS内核+中间件”的一套完整的“操作系统”。 AUTOSAR CP定义了基本的上层任务调度、优先级调度等。
在基于分布式架构的ADAS功能中，AUOTSAR CP便是最常见的“操作系统”。在AUTOSAR的生态形成后，很多芯片厂商的MCU上标配的就是AUTOSAR CP，主机厂没有什么选择权。
由于分布式架构下的芯片主要是MCU，因此，便有了“AUTOSAR CP主要跑在MCU上”的说法。
在分布式架构下，不同的功能对应着不同的MCU，而每一个MCU上都需要跑一套AUTOSAR CP，若传感器的类型比较多，则仅ADAS相关功能就需要很多套AUTOSAR CP，那怎么收费呢？
常规的做法是：根据MCU的类型来收费——如果MCU是两个异构的MCU，那AUTOSAR CP就按两套来收费；如果MCU是同构的，那AUTOSAR CP就按一套来收费。
随着EE架构从分布式向集中式演进、芯片由MCU向SOC演进，计算量及通信量成数量级地上升，另外，多核处理器、GPU、FPGA以及专用加速器的需求，还有OTA等，都超出了AUTOSAR CP的支持范围。
（图片摘自安志鹏的直播课）
2017年，为更好地满足集中式架构+SOC时代的高等级自动驾驶对中间件的需求，AUTOSAR联盟推出了通信能力更强、软件可配置性更灵活、安全机制要求更高的AUTOSAR AP平台。
需要强调的是，不同于AUTOSAR CP自身已经包含了基于OSEK标准的OS，AUTOSAR AP只是一个跑在Lunix、QNX等基于POSIX标准的OS上面的中间件——它自身并不包含OS。
结合aFakeProgramer于2020年发表在CSDN上的《为什么要用AP？Adaptive AutoSAR到底给企业提供了一些什么？》一文及东软睿驰安志鹏在2022年春节前的一场直播中讲的内容，AUTOSAR CP与AUTOSAR AP最主要的区别有如下几点：
1）.编程语言不同——AUTOSAR CP基于C语言，而AUTOSAR AP基于C++语言；
2）.架构不同——AUTOSAR CP 采用的是FOA架构（function-oriented architecture），而AUTOSAR AP采用的则是SOA架构（service-oriented architecture）；
3）.通信方式不同——AUTOAR CP采用的是基于信号的静态配置通信方式（LIN\CAN...通信矩阵），而AUTOSAR AP采用的是基于服务的SOA动态通信方式（SOME/IP）；
4）.连接关系不同——在AUTOSAR CP中，硬件资源的连接关系受限于线束的连接，而在AUTOSAR AP中，硬件资源间的连接关系虚拟化，不局限于通信线束的连接关系；
5）.调度方式不同——AUTOSAR CP采用固定的任务调度配置，模块和配置在发布前进行静态编译、链接，按既定规则顺序执行，而AUTOSAR CP则支持多种动态调度策略，服务可根据应用需求动态加载，并可进行单独更新。
6）.代码执行和地址空间不同——AUTOSAR CP中，大部分代码静态运行在ROM，所有application共用一个地址空间，而在AUTOSAR AP中，应用加载到RAM运行，每个application独享（虚拟）一个地址空间。
这些区别，带给AUTOSAR AP的优势有如下几点——
1）.ECU更加智能：基于SOA通信使得AP中ECU可以动态的同其他ECU同其他ECU进行连接，提供或获取服务；
2）.更强大的计算能力：基于SOA架构使得AP能够更好地支持多核、多ECU、多SoCs并行处理，从而提供更强大的计算能力；
3).更加安全：基于SOA架构使得AP中各个服务模块独立，可独立加载，IAM管理访问权限；
4).敏捷开发：Adaptive AUTOSAR服务不局限于部署在ECU本地可分布于车载网络中，使得系统模块可灵活部署，后期也能灵活独立更新（FOTA）；
5).高通信带宽：可实现基于Ethernet等高通信带宽的总线通信；
6).更易物联：基于以太网的SOA通信，更易实现无线、远程、云连接，方便部署V-2-X应用。
（图片摘自东软睿驰）
当然了，在某些方面，AUTOSAR AP与AUTOSAR CP相比是有一些“劣势”的。比如，AUTOSAR CP的时延可低至微秒级、功能安全等级达到了ASIL-D，硬实时；而AUTOSAR AP的时延则在毫秒级，功能安全等级则为ASIL-B，软实时。
上述区别也导致了两者应用领域的不同：AUTOSAR CP一般应用在对实时性和功能安全要求较高、对算力要求较低的场景中，如引擎控制、制动等传统ECU；而AUTOSAR则应用在对实时性和功能安全有一定要求，但对算力要求更高的场景中，如ADAS、自动驾驶，以及在动态部署方面追求较高自由度的信息娱乐场景。
尽管AUTOSAR AP有种种优点，但总的来说，它目前还不够成熟——主要是信息安全及UCM等模块不成熟。量产车上装AUTOSAR AP的不少，但主要用在娱乐场景，真正用在自动驾驶场景的还很少。
此外，由于SOC+MCU组合的现象会长期存在，因而，在今后相当长一段时间内，AUTOSAR AP都不可能彻底取代AUTOSAR CP——最常见的分工会是，需要高算力的工作交给AUTOSAR AP,而需要高实时性的工作则交给AUTOSAR CP。
（图片摘自超星未来）
2.ROS 2
ROS是机器人操作系统（Robot Operating System）的英文缩写，原生的ROS本是机器人OS，并不能直接满足无人驾驶的所有需求，用作自动驾驶中间件的是ROS 2。
ROS 2与ROS 1的主要区别如下：
（1）.ROS 1主要构建于Linux系统之上，主要支持Ubuntu；ROS 2采用全新的架构，底层基于DDS(Data Distribution Service)通信机制，支持实时性、嵌入式、分布式、多操作系统，ROS 2支持的系统包括Linux、windows、Mac、RTOS，甚至是单片机等没有操作系统的裸机。
（2）.ROS 1的通讯系统基于TCPROS/UDPROS，强依赖于master节点的处理；ROS 2的通讯系统是基于DDS，取消了master，同时在内部提供了DDS的抽象层实现，有了这个抽象层，用户就可以不去关注底层的DDS使用了哪个商家的API。
（3）.ROS运行时要依赖roscore，一旦roscore出现问题就会造成较大的系统灾难，同时由于安装与运行体积较大，对很多低资源系统会造成负担；ROS2基于DDS进行数据传输，而DDS基于RTPS的去中心化的通信框架，这就去除了对roscore的依赖，系统的稳定性强，对资源的消耗也得到了降低。
(4).由于ROS 缺少Qos机制，topic的稳定性与质量难以保证；ROS2则提供了Qos机制，对通信的实时性、完整性、历史追溯等功能有了支持，这便大幅加强了框架功能，避免了高速系统难以适用等问题。
不过，ROS2的QoQ配置较为复杂，目前主要是国外一些专业的大学或实验室在使用,国内仅有极少数公司在尝试;此外，ROS 2的生态成熟度远不如ROS,这也给推广应用带来了不便。
跟AUTOSAR AP一样，ROS 2也是跑在soc芯片上、用于满足高等级自动驾驶的需求的。不过，萧猛在去年的一批文章中却特别强调：当我们称 “ROS/ROS2 为中间件”时，其含义与 “AUTOSAR AP为 中间件”并不是对等的关系。
萧猛的文章称：
当我们说 AutoSar是中间件时，这个中间件是很明确的 L.BSW层语义，即处于计算机OS与车载ECU特定功能实现之间，为 ECU功能实现层屏蔽掉特定处理器和计算机OS相关的细节，并提供与车辆网络、电源等系统交互所需的基础服务；
ROS/ROS2 是作为机器人开发的应用框架，在机器人应用和计算机OS之间提供了通用的中间层框架和常用软件模块(ROS Package)，而且， ROS团队认为这个框架做得足够好，可以称作操作系统（OS）了。
ROS 2尽管在功能上跟AUTOSAR AP有不少重叠之处，但两者的思路是不一样的：
（1）.从表现形式上看，AUTOSAR AP首先是一套标准，这个标准定义了一系列基础平台组件，每个平台组件定义了对应用的标准接口，但没有定义实现细节，和平台组件之间的交互接口（这些部分留给AUTOSAR AP供应商实现）；ROS2则从一开始就是代码优先，每个版本都有完整的代码实现，也定义有面向应用标准API接口。
（2）AUTOSAR AP从一开始就面向ASIL-B应用；ROS 2不是根据ASIL的标准设计的，ROS 2实现功能安全的解决方案是，把底层换为满足ASIL要求的RTOS和商用工具链(编译器）。
ROS 2“过不了车规”似乎已成为一个很广泛的行业共识。但在萧猛看来，ROS2本来就不是为实时域设计的，如果一定要把实时性要求高的车辆控制算法运行在 ROS2中，“那是软件设计的错误，而不是ROS2的问题”。
萧猛认为，只要能补齐 L.BSW层所需要完成的所有功能、补齐 A 轴所有切面要求的特性，ROS 2就能用于自动驾驶量产车。如前段时间刚拿到采埃孚等多家巨头投资的Apex.AI公司基于ROS 2定制开发的Apex.OS就已经通过了最高等级的ASIL D认证。
萧猛说：“这实际上是基于 ROS 2的架构去实现一套 AUTOSAR AP 规范。这可以成为一个单独的产品，投入时间+人+钱可以开发出来，只是看有没有必要，值不值得”。
在具体的实践中，ROS 2跟AUTOSAR AP存在直接竞争关系——尽管对用户来说，并不存在严格意义上的“二选一”问题，但通常来说，若选了ROS 2，就不会选AUTOSAR AP了；若选了AUTOSAR AP，就不会选ROS 2了。
3. CyberRT
Cyber RT是网络Apollo开发出来的中间件，在Apollo 3.5中正式发布。Cyber RT和ROS2是比较像的， 其底层也是使用了一个开源版本的DDS。
网络最早用的是ROS 1,但在使用的过程中逐渐发现了ROS 1存在“若ROS Master出故障了，则任何两个节点之间的通信便受到影响”的问题，所以就希望使用一个“没有中间节点”的通信中间件来代替ROS 1，那时还没有ROS2，所以自己去做了一个Cyber RT。
为了解决 ROS 遇到的问题，Cyber RT删除了master机制，用自动发现机制代替，这个通信组网机制和汽车网络CAN完全一致。此外，Cyber RT的核心设计将调度、任务从内核空间搬到了用户空间。
（图片出处：https://blog.csdn.net/xhtchina/article/details/118151673）
其相对于其他系统，Cyber RT的一大优势是，专为无人架驶设计。网络已将Cyber RT开源，某互联网巨头的自动驾驶团队使用的中间件便是网络开源出来的Cyber RT。
Cyber RT跟ROS 2之间也存在竞争关系。
在谈到AUTOSAR AP、ROS 2与Cyber RT这些中间件的关系时，Vector产品专家蔡守群的解释是：
“不需要很机械地去分类，你可以把AUTOSAR AP, ROS和Cyber RT都想象成一个提供一组中间件的超市，用户可以按需从不同的超市购买，并不是说从一个超市买过一个中间件，就不能从其他超市买了。
蔡守群说：AUTOSAR AP中也包含了对ROS接口的支持。说不准哪天ROS和Cyber RT就会加入AUTOSAR AP的组件，或者 AUTOSAR AP会引入Cyber RT的组件。
4.DDS（通信中间件）
（1）什么是DDS？
在自动驾驶领域，中间件的功能涉及到通信、模块升级、任务调度、执行管理，但其最主要的功能就是通信。当前市场上，无论是Cyber RT还是 ROS，基本上90%的功能就是通信，狭义上说就是通信中间件。
通信中间可以分成开源和闭源的两种。开源的为OPEN DDS、FAST DDS、Cyclone等，闭源的就RTI的DDS和Vector的SOME/IP。DDS的全称为Data Distribution Service ，指一种数据分发服务标准，由对象管理组织(OMG)制定。
DDS能够实现低延迟、高可靠、高实时性的数据融合服务，能够从根本上降低软件的耦合性、复杂性，提高软件的模块化特性。高等级自动驾驶现在基本上都在探索依靠DDS来解决异构通信、低时延等CP解决不了的挑战。
融合了DDS的汽车软件能够更好地运行在下一代汽车的体系架构中，更能降低开发的成本、缩短研发的时间，更快地将产品推向市场。
（2）DDS与ROS 2、AUTOSAR AP之间的关系
ROS 2和Cyber RT的底层都使用了开源的DDS，将DDS作为最重要的通信机制。但也有自动驾驶公司的工程师认为，DDS可以起到替代ROS 2的作用，站在用户的角度看，两者之间其实存在“二选一”的关系。
AUTOSAR CP里一直没有包含跟DDS有关的东西，但AUTOSAR AP在 2018年3月的最新版（版本18-10）里开始支持DDS标准。将DDS与AUTOSAR AP结合使用，不仅可以保证和扩展AUTOSAR AP系统内部互操作性的功能，而且还可以将其开放给来自不同的生态系统（即ROS 2）。
从工程角度来看，将AUTOSAR和DDS结合起来的最大优势是，功能域和网络拓扑不再是对手，而是车辆中的盟友。网络拓扑结构能够更好地适应车辆的物理约束，功能域在物理车辆的顶部提供了一个灵活的覆盖层，这就是所谓的分区体系结构。
当然，DDS仅是通信中间件的一种。关于各类通信中间件之间的异同，我们将在本系列的第二篇做更详细的阐释。
三．AUTOSAR AP的地位正在弱化？
尽管AUTOSAR是当下最有名的自动驾驶中间件，但《九章智驾》在对诸多中间件厂商们的调研中得出一个结论：AUTOSAR在产业链中的地位可能正在弱化。 当然了，那些专注于AUTOSAR系统的厂商们并不认同这一观点。
我们在上文已经提到，随着EE架构从分布式向集中式演进、MCU被SOC取代，CP AUTSAR被AUTOSAR AP、ROS 2和Cyber RT等取代已是大势所趋，在下文，我们主要谈的是“AUTOSAR AP的地位会不会弱化”。
2021年12月中旬，两家AUTOSAR发起公司大陆集团、丰田联合采埃孚、積架路虎、沃尔沃、海拉等多家汽车行业龙头企业宣布投资车载操作系统初创公司Apex.AI，而Apex.AI的主力产品Apex.OS则是基于ROS 2发展起来的。
拿到了Apex.AI公司15%股权的采埃孚方面在接受媒体采访时说：“这意味着，我们可以为客户提供AUTOSAR AP的替代方案。”
尽管AUTOSAR AP已经有了标准，但还没有落地。安波福、采埃孚、大陆这些公司提供的方案，仍然是基于AUTOSAR CP标准的接口。事实上，越来越多的OEM不太想完全用AUTOSAR去解决智能驾驶操作系统的问题。
不仅特斯拉没有用AUTOSAR AP,国内的几大造车新势力也没有用(他们用的是AUTOSAR CP+DDS)。甚至，连一些正在转型的传统车企也没打算用AUTOSAR AP。
从产业链中各方的反应来看，AUTOSAR AP“地位不稳”的原因主要有以下几个：
1．使用成本太高
冯占军博士在《AUTOSAR对基础软件开发是喜还是忧？》一文中透露，AUTOSAR的费用通常是“几百万起”，并且，针对不同的域控制器、不同的芯片需要“重复收费”，一般小厂根本吃不消。“可能还没有什么产出，几百万就花出去了”。
除购买成本高外，毕晓鹏和萧猛都提到，AUTOSAR前期的学习难度很大、学习成本也非常高。为了学会如何使用AUTOSAR,企业甚至不得不专门培训一批人,如果受培训的人临时离职了，那培训费用就打了水漂。
2.效率不高
毕晓鹏认为，AUTOSAR AP的配置非常多，它是通过配置加上一部分代码去实现自己的功能，但配置多了之后，效率不高，而且代码臃肿。
3.静态部署与动态部署的理念冲突
毕晓鹏博士提到，AUTOSAR AP其实是从AUTOSAR CP发展而来的，AUTOSAR CP是静态部署，只适用于相对简单的业务逻辑和功能，其代码是固化的，有点像以前的功能手机——功能无法改变，不可能往里面再加一个APP；但AUTOSAR AP有点像现在的智能手机，软件开发人员开发一个APP，跨平台就可以用不同手机上了，这种动态部署的理念和之前的静态部署概念不甚相同，而其方法论却是基于静态部署衍生而来的，因此在实践层面会遇到不少问题。
4.无法满足智能网联的需求
由于云端跟车端所使用的操作系统不一样，AUTOSAR只能负责车内的通信，不能支持车端到云端的通信，因而无法支持车路协同场景（车端跟云端的通信，是通过MQTT、kafka等中间件来实现的）。除此之外，AUTOSAR能否兼容车辆网联化中需要用到的数据平台、通信平台和地图平台，也存在很大的疑问。
毕晓鹏说，在发现了这些问题后，有一些OEM开始逐渐放弃AUTOSAR架构，“转而自己去研发一套更适合动态部署、成本较低的新型软件架构”。
传统车厂是从使用CP过来的，所以在惯性上，他们可能还会考虑AP是否适合智能驾驶，但慢慢地也在尝试转型。如奥迪和TTTech合作做的通信中间件——zFAS，也没有采用AP。
不同于AUTOSAR CP已经是非常标准化的东西，大家用起来没什么问题，AUTOSAR AP现在的标准也不是很完善，每年也在更新，具体AP能发展成什么样，这个谁也不知道，大家更多也是观望的态度。
毕晓鹏认为，AUTOSAR标准并不能很好地支撑自动驾驶应用和创新的发展，因此，我们有必要建立一套更适合中国智能驾驶发展、且自主可控的技术架构和生态体系。
萧猛认为，由于从AUTOSAR CP到AUTOSAR AP一脉相承，一些已经对AUTOSAR形成路径依赖的公司会坚持使用AUTOSAR AP,但在经历过招人难、开发周期长等教训之后，他们有可能转向ROS 2。
当然，以AUTOSAR为主业的公司，显然不会认可上述“涉嫌唱衰”AUTOSAR AP的观点的。
比如，Vector蔡守群就认为，AUTOSAR AP只会越来越重要，因为它是顺应车载技术不断发展的一套规范，覆盖面会越来越广。
东软睿驰茅海燕也认为，要将整车域控制器和智驾域控制器合并到统一的中央计算平台上，没有AUTOSAR AP的支持很难搞定。“不是每家公司都能像特斯拉一样自己从头搭建系统的，目前,最好的工具还是AUTOSAR AP”。
❻ IDL是什么东西
分类: 商业/理财 >> 贸易
问题描述:
IDL是什么东西？
解析:
Java IDL（Interface Definition Language，接口定义语言）为 JavaTM 平台添加了 CORBA（Common Object Request Broker Architecture，公用对象请求代理体系结构）功能，从而可提供基于标准的互操作性和连接性。Java IDL 使胡老分布式、支持 Web 的 Java 应用程序可利用 Object Management Group 定义的行业标准 OMG IDL（Object Management Group Interface Definition Language，对象管理组接口定义语言）及 IIOP（Inter Inter-ORB Protocol，Inter对象请求代理间协议）来透明地调用远程网络服务。运行时组件包括一个全兼容的 Java ORB，用于通过 IIOP 通讯进行分布裤胡升式计算做携。要使用 Java IDL，用户必须具有 idltojava 编译器。
❼ 什么是中间件
中间件是一种独立的系统软件或服务程序，分布式应用软件借助这种软件在不同的技术之间共享资源。中间件位于客户机/ 服务器的操作系统之上，管理计算机资源和网络通讯。是连接两个独立应用程序或独立系统的软件。相连接的系统，即使它们具有不同的接口，但通过中间件相互之间仍能交换信息。
执行中间件的一个关键途径是信息传递。通过中间件，应用程序可以工作于多平台或OS环境。
中间件是基础软件的一大类猜哗，属于可复用软件的灶兆游范畴。顾名思义，中间件处于操作系统软件与用户的应用软件的中间。
(7)OMG编译器扩展阅读
中间件在操作系统、网络和数据库之上，应用软件的下层，总的作用是为处于自己上层的应用软件提供运行与开发的环境，帮助用户灵活、高效地开发和集成复杂的应用软件。
在众多关于中间件的定义中，比较普遍被接受的是IDC表述的：中间件是一种独立的系统软件或服务程序，分布式应用软件借助这种软件在不隐销同的技术之间共享资源，中间件位于客户机服务器的操作系统之上，管理计算资源和网络通信。
由于标准接口对于可移植性、标准协议对于互操作性的重要性，中间件已成为许多标准化工作的主要部分。对于应用软件开发，中间件远比操作系统和网络服务更为重要，中间件提供的程序接口定义了一个相对稳定的高层应用环境，不管底层的计算机硬件和系统软件怎样更新换代，只要将中间件升级更新，并保持中间件对外的接口定义不变，应用软件就几乎不需任何修改，从而保护了企业在应用软件开发和维护中的重大投资。
❽ 硬件与软件的区别是什么
一、软件是一种逻辑的产品，与硬件产品有本质的区别
硬件是看得见、摸得着的物理部件或设备。在研制硬件产品时，人的创造性活动表现在把原材料转变成有形的物理产品。
而软件产品是以程序和文档的形式存在，通过在计算机上运行来体现他的作用。在研制软件产品的过程中，人们的生产活动表现在要创造性地抽象出问题的求解模型，然后根据求解模型写出程序，最后经过调试、运行程序得到求解问题的结果。整个生产、开发过程是在无形化方式下完成的，其能见度极差，这给软件开发、生产过程的管理带来了极大的困难。
二、软件产品质量的体现方式与祥埋硬件产品不同
质量体现方式不同表现在两个方面。硬件产品设计定型后可以批量生产，产品质量通过质量检测体系可以得到保障。但是生产、加工过程一旦失误。硬件产品可能就会因为质量问题而报废。而软件产品不能用传统意义上的制造进行生产，就目前软件开发技术而言缓银，软件生产还是“定制”的，只能针对特定问题进行设计或实现。但是软件爱你产品一旦实现后，其生产过程只是复制而已，而复制生产出来的软件质量是相同的。设计出来的软件即使出现质量问题，产品扰宴宴也不会报废，通过修改、测试，还可以将“报废”的软件“修复”，投入正常运行。可见软件的质量保证机制比硬件具有更大的灵活性。
三、软件产品的成本构成与硬件产品不同
硬件产品的成本构成中有形的物质占了相当大的比重。就硬件产品生存周期而言，成本构成中设计、生产环节占绝大部分，而售后服务只占少部分。
软件生产主要靠脑力劳动。软件产品的成本构成中人力资源占了相当大的比重。软件产品的生产成本主要在开发和研制。研制成功后，产品生产就简单了，通过复制就能批量生产。
四、软件产品的失败曲线与硬件产品不同
硬件产品存在老化和折旧问题。当一个硬件部件磨损时可以用一个新部件去替换他。硬件会因为主要部件的磨损而最终被淘汰。
对于软件而言，不存在折旧和磨损问题，如果需要的话可以永远使用下去。但是软件故障的排除要比硬件故障的排除复杂得多。软件故障主要是因为软件设计或编码的错误所致，必须重新设计和编码才能解决问题。
软件在其开发初始阶段在很高的失败率，这主要是由于需求分析不切合实际或设计错误等引起的。当开发过程中的错误被纠正后，其失败率便下降到一定水平并保持相对稳定，直到该软件被废弃不用。在软件进行大的改动时，也会导致失败率急剧上升。
五、大多数软件任然是定制产生的
硬件产品一旦设计定型，其生产技术、加工工艺和流程管理也就确定下来，这样便于实现硬件产品的标准化、系列化成批生产。由于硬件产品具有标准的框架和接口，不论哪个厂家的产品，用户买来都可以集成、组装和替换使用。
尽管软件产品复用是软件界孜孜不倦追求的目标，在某些局部范围内几家领军软件企业也建立了一些软件组件复用的技术标准。例如，OMG的CORBA,mICROSOFT的COM，sun的J2EE等，但是目前还做不到大范围使用软件替代品。大多数软件任然是为特定任务或用户定制的。
❾ 什么是MOF 文件
托管对象格式(MOF)文件是创建和注册提供程序、事件类别和事件的简便方法。
下面来了解下“MOF”：
对象机制（MOF，Meta-ObjectFacility）起源于统一建模语言（UML）。对象管理机构（ObjectManagementGroup|OMG）需要一种元模型结构来定义UML。
MOF是一个游梁封闭元模型结构，它定义谨液描述自身的M3模型。MOF是严格的元模型架构，每一层的每个模型元素都严格对应的上层模型元素。MOF只提供定义结构或语言、数据的抽象语法的方法神晌运。定义元模型时，MOF如同EBNF层定义编程语言语法。MOF是用于定义元模型的域特定语言（DSL），就像EBNF定义语法的DSL。同样，MOF也可以在自身定义。
MOF现在是一个国际标准：ISO/IEC19502:2005Informationtechnology—MetaObjectFacility(MOF)
MOF可视为写元模型的标准，例如，建模领域专用语言的抽象语法。Kermeta扩展MOF,可以执行附在EMOF元模型的动作，从而可以建模DSL操作语义并很容易得到对它的解释。
❿ IDL的简介
IDL是用来描述软件组件接口的一种计算机语言。IDL通过一种中立的方式来描述接口，使得在不同平台上运行的对象和用不同语言编写的程序可以相互通信交流；比如，一个组件用C++写成，另一个组件用Java写成。
IDL通常用于远程调用软件。 在这种情况下，一般是由远程客户终端调用不同操作系统上的对象组件，并且这些对象组件可能是由不同计算机语言编写的。IDL建立起了两个不同操作系统间通信的桥梁。
从本质上讲，OMG IDL接口定义语言不是作为程序设计语言体现在CORBA体系结构中的，而是用来描述产生对象调用请求的客户对象和服务对象之间的接口的语言。OMG IDL文件描述数据类型和方法框架，而服务对象则为一个指定的对象实现提供上述数据和方法。
OMG IDL文件描述了服务器提供的服务功能，客户机可以根据该接口文件描述的方法向服务器提出业务请求。在大多数CORBA产品中都提供IDL到相关编程语言的编译器。程序设计人员只需将定义的接口文件输入编译器，设定编译选项后，就可以得到与程序设计语言相关的接口框架文件和辅助文件。IDL文件应用过程如图1所示 。