计算机专业外文文献翻译6

外文文献翻译（译成中文2000字左右）：

As research laboratories become more automated,new problems are arising for laboratory managers.Rarely does a laboratory purchase all of its automation from a single equipment vendor. As a result,managers are forced to spend money training their users on numerous different software packages while purchasing support contracts for each. This suggests a problem of scalability. In the ideal world,managers could use the same software package to control systems of any size; from single instruments such as pipettors or readers to large robotic systems with up to hundreds of instruments. If such a software package existed, managers would only have to train users on one platform and would be able to source software support from a single vendor.

If automation software is written to be scalable, it must also be flexible. Having a platform that can control systems of any size is far less valuable if the end user cannot control every device type they need to use. Similarly, if the software cannot connect to the customer’s Laboratory Information Management System (LIMS) database,it is of limited usefulness. The ideal automation software platform must therefore have an open architecture to provide such connectivity.

Two strong reasons to automate a laboratory are increased throughput and improved robustness. It does not make sense to purchase high-speed automation if the controlling software does not maximize throughput of the system. The ideal automation software, therefore, would make use of redundant devices in the system to increase throughput. For example, let us assume that a plate-reading step is the slowest task in a given method. It would make that if the system operator connected another identical reader into the system, the controller software should be able to use both readers, cutting the total throughput time of the reading step in half. While resource pooling provides a clear throughput advantage, it can also be used to make the system more robust. For example, if one of the two readers were to experience some sort of error, the controlling software should be smart enough to route all samples to the working reader without taking the entire system offline.

Now that one embodiment of an ideal automation control platform has been described let us see how the use of C++ helps achieving this ideal possible.

DISCUSSION

C++: An Object-Oriented Language

Developed in 1983 by BjarneStroustrup of Bell Labs,C++ helped propel the concept of object-oriented programming into the mainstream.The term ‘‘object-oriented programming language’’ is a familiar phrase that has been in use for decades. But what does it mean? And why is it relevant for automation software? Essentially, a language that is object-oriented provides three important programming mechanisms:

encapsulation, inheritance, and polymorphism.

Encapsulation is the ability of an object to maintain its own methods (or functions) and properties (or variables).For example, an ‘‘engine’’ object might contain methods for starting, stopping, or accelerating, along with properties for ‘‘RPM’’ and ‘‘Oil pressure’’. Further, encapsulation allows an object to hide private data from a ny entity outside the object. The programmer can control access to the object’s data by marking methods or properties as public, protected,or private. This access control helps abstract away the inner workings of a class while making it obvious to a caller which methods and properties are intended to be used externally.

Inheritance allows one object to be a superset of another object. For example, one can create an object called Automobile that inherits from Vehicle. The Automobile object has access to all non-private methods and properties of Vehicle plus any additional methods or properties that makes it uniquely an automobile.

Polymorphism is an extremely powerful mechanism that allows various inherited objects to exhibit different behaviors when the same named method is invoked upon them. For example, let us say our Vehicle object contains a method called CountWheels. When we invoke this method on our Automobile, we learn that the Automobile has four wheels.However, when we call this method on an object called Bus,we find that the Bus has 10 wheels.Together, encapsulation, inheritance, and polymorphism help promote code reuse, which is essential to meeting our requirement that the software package be flexible. A vendor can build up a comprehensive library of objects (a serial communications class, a state machine class, a device driver class,etc.) that can be reused across many different code modules.A typical control software vendor might have 100 device drivers. It would be a nightmare if for each of these drivers there were no building blocks for graphical user interface (GUI) or communications to build on. By building and maintaining a library of foundation objects, the vendor will save countless hours of programming and debugging time.

All three tenets of object-oriented programming are leveraged by the use of interfaces. An interface is essentially a specification that is used to facilitate communication between software components, possibly written by different vendors. An interface says, ‘‘if your cod e follows this set of rules then my software component will be able to communicate with it.’’ In the next section we will see how interfaces make writing device drivers a much simpler task.

C++ and Device Drivers

In a flexible automation platform, one optimal use for interfaces is in device drivers. We would like our open-architecture software to provide a generic way for end users to write their own device drivers without having to divulge the secrets of our source code to them. To do this, we define a simplified

C++ interface for a generic device, as shown here:

class IDevice

{

public:

virtual string GetName() ? 0; //Returns the name

//of the device

virtual void Initialize() ? 0; //Called to

//initialize the device

virtual void Run() ? 0; // Called to run the device

};

In the example above, a Ctt class (or object) called IDevice has been defined. The prefix I in IDevice stands for ‘‘interface’’. This class defines three public virtual methods: GetName, Initialize, and Run. The virtual keyword is what enables polymorphism, allowing the executing program to run the methods of the inheriting class. When a virtual method declaration is suffixed with ?0, there is no base class implementation. Such a method is referred to as ‘‘pure virtual’’. A class like IDevice that contains only pure virtual functions is known as an ‘‘abstract class’’, or an

‘‘interface’’. The IDevice definition, along with appropriate documentation, can be published to the user community,allowing developers to generate their own device drivers that implement the IDevice interface.

Suppose a thermal plate sealer manufacturer wants to write a driver that can be controlled by our software package. They would use inheritance to implement our IDevice interface and then override the methods to produce the desired behavior: class CSealer : public IDevice

{

public:

virtual string GetName() {return ‘‘Sealer’’;}

virtual void Initialize() {InitializeSealer();}

virtual void Run() {RunSealCycle();}

private:

void InitializeSealer();

void RunSealCycle();

};

Here the user has created a new class called CSealer that inherits from the IDevice interface. The public methods,those that are accessible from outside of the class, are the interface methods defined in IDevice. One, GetName, simply returns the name of the device type that this driver controls.The other methods,Initialize() and Run(), call private methods that actually perform the work. Notice how the private

keyword is used to prevent external objects from calling InitializeSealer() and RunSealCycle() directly.When the controlling software executes, polymorphism will be used at runtime to call the GetName, Initialize, and Run methods in the CSealer object, allowing the device defined therein to be controlled.

DoSomeWork()

{

//Get a reference to the device driver we want to use

IDevice&device ? GetDeviceDriver();

//Tell the world what we’re about to do.

cout !! ‘‘Initializing ’’!! device.GetName();

//Initialize the device

device.Initialize();

//Tell the world what we’re about to do.

cout !! ‘‘Running a cycle on ’’ !!

device.GetName();

//Away we go!

device.Run();

}

The code snippet above shows how the IDevice interface can be used to generically control a device. If GetDevice-Driver returns a reference to a CSealer object, then DoSomeWork will control sealers. If GetDeviceDriver returns a reference to a pipettor, then DoSomeWork will control pipettors. Although this is a simplified example, it is straightforward to imagine how the use of interfaces and polymorphism can lead to great economies of scale in controller software development.

Additional interfaces can be generated along the same lines as IDevice. For example, an interface perhaps called ILMS could be used to facilitate communication to and from a LIMS.

The astute reader will notice that the claim that anythird party can develop drivers simply by implementing the IDevice interface is slightly flawed. The problem is that any driver that the user writes, like CSealer, would have to be linked directly to the controlling software’s exec utable to be used. This problem is solved by a number of existing technologies, including Microsoft’s COMor .NET, or by CORBA. All of these technologies allow end users to implement abstract interfaces in standalone components that can be linked at runtime rather than at design time. The details are beyond the scope of this article.

中文翻译：

随着研究实验室更加自动化，实验室管理人员出现的新问题。很少有实验室向一个供应商

购买其所有自动化设备。因此，管理人员被迫花钱，同时为每个采购支持合同训练他们对

各种不同的软件服务包的用户。这表明可伸缩性问题。在理想的世界中，管理者可以使用

相同的软件程序包，到控制系统的任意的大小；从单一文书如移液器或大型机器人系统读者达数百种仪器。如果已存在一个软件包，管理人员只需从单一的供应商在一个平台上的

得到用户培训和能源软件支持。

如果编写自动化软件进行扩展，它还必须灵活。有一个平台，可以控制任何大小的系统是

远没有那么宝贵，如果最终用户不能控制他们需要使用的每个设备类型。同样，如果软件

无法连接到客户的实验室信息管理系统 (LIMS）数据库,是的用处有限。理想的自动化软

件平台因此必须具有开放的体系结构，提供这种连接。

增加的吞吐量和改进的假死的自动化实验室的两个强劲的原因。它不清楚购买高速自动化，如果控制软件不会未最大化的系统的吞吐量。理想的自动化的软件，因此，会使系统中的

冗余设备使用的增加吞吐量。例如，让我们假设板阅读迈出的一步是在给定的方法中最慢

的任务。它将使，如果系统操作员连接到系统的另一个完全相同的读卡器，控制器软件应

该能够使用这两种阅读器，节省一半的总吞吐量时间阅读步骤。虽然资源池提供了一个明

确的吞吐量的优势，它还可以用来使系统更强健。例如，如果两个读者之一是某种错误的

经验，应该足够智能路由到工作读卡器的所有样本不让整个系统离线的情况下控制软件。

现在已被描述的理想自动化控制平台这一体现，让我们看到如何使用 c + + 帮助实现这种理想的可能。

在 1983 年由BjarneStroustrup的贝尔实验室的发展，c + + 推动面向对象编程的概念纳

入主流。术语面向对象的编程语言是熟悉的短语，几十年来使用了。但它又意味着什么呢？又为什么说它相关的自动化软件？实质上，一是面向对象的语言提供了三个重要编程机制：封装、继承和多态性。

封装是维持其自己的方法（或功能）对象的能力和属性（或变量）。例如，引擎对象可能会包含方法启动、停止或加速，随着 'RPM ' 和油压力的属性。进一步，封装，允许一个对象以隐藏对象以外的任何实体的私人数据。程序员可以通过标记的方法或属性为公共

的受保护的或私人控制对象的数据的访问。此访问控制可以帮助走了抽象类的内部工作，

同时使它明显到调用方的方法和属性拟供外部使用。

继承允许一个对象成为另一个对象的超集。例如，一个可以创建的对象称为车辆从继承的

汽车。汽车对象可以访问所有非私有方法和属性的车辆加任何其他方法或属性，使它成为

唯一的汽车。

多态性是一种非常强大的机制，允许各类继承的对象相同的命名的方法调用在他们身上时，表现出不同的行为。例如，让我们假设我们车辆对象包含调用 CountWheels 方法。我们在我们的汽车上调用此方法，当我们学习汽车有四个轮子。然而，当我们称为总线的对象上

调用此方法，我们发现公共汽车已 10 轮。一起封装、继承和多态性帮助促进代码重用，这是基本符合我们要求的软件包可灵活。供应商可以建立全面的跨许多不同的代码模块可

重复使用的对象（串行通信类、状态机类、设备驱动程序类等）的库。一个典型的控

制软件供应商可能有 100 的设备驱动程序。如果这些驱动程序的每个有没有构造块的图形

用户界面 (GUI) 或通信的基础上，它将是一场噩梦。通过构建和维护基础对象的库，供应商将节省无数小时的编程和调试时间。

所有三个信条的面向对象的编程接口的使用都可利用。接口是本质上是一个规范，用于促进可能是由不同的供应商编写的软件组件之间的沟通。接口说，如果你的代码遵循这套规则然后我的软件组件将能够与之联系。在下一节中我们将会看到如何接口使编写设备驱动程序多的简单任务。

一个灵活的自动化平台上，一个优化使用的接口是设备驱动程序。我们想要我们的开放式软件提供的最终用户可以编写自己的设备驱动程序，而不必将我们的源代码的秘密泄露给他们的泛型方法。为此，我们定义简化的 c + + 接口的通用设备，如下所示：

class IDevice

{

public:

virtual string GetName() ? 0; //Returns the name

//of the device

virtual void Initialize() ? 0; //Called to

//initialize the device

virtual void Run() ? 0; // Called to run the device

};

在上面的示例中，铁通类（或对象）称为 IDevice 已经定义。前缀 IDevice 在我代表接口。此类定义三个公共的虚拟方法： GetName，初始化，并运行。虚拟关键字是类的一种使多态性，允许执行的程序运行继承的方法。当虚拟方法声明的后缀的？ 0，没有任何基类实现。这种方法被称为纯虚拟。像 IDevice 包含只纯虚函数的类称为抽象类或接口。IDevice 的定义，连同相应的文档，可以发布到用户社区，允许开发人员可以生成自己实现 IDevice 接口的设备驱动程序。

假设热板封口机制造商想要写一个驱动程序，可以通过我们的软件程序包进行控制。他们将使用继承来实现我们的 IDevice 接口，然后重写的方法，以产生所需的行为：

class CSealer : public IDevice

{

public:

virtual string GetName() {return ‘‘Sealer’’;}

virtual void Initialize() {InitializeSealer();}

virtual void Run() {RunSealCycle();}

private:

void InitializeSealer();

void RunSealCycle();

};

在这里已创建一个新的类称为 CSealer 从 IDevice 接口继承的用户。公共方法，那些可以从类以外的访问是 IDevice 中定义的接口方法。一，GetName，只返回此驱动程序控制

的设备类型的名称。其他方法,Initialize() 和 Run()，调用的私有方法，实际上执行的工作。请注意如何 private 关键字用于防止外部对象直接调用 InitializeSealer() 和RunSealCycle()。控制软件执行时，多态性将用于在运行时调用 CSealer 对象，对象允许定义其中所能控制的设备中的 GetName、初始化和运行方法。

{

//Get a reference to the device driver we want to use

IDevice&device ? GetDeviceDriver();

//Tell the world what we’re about to do.

cout!! ‘‘Initializing ’’!! device.GetName();

//Initialize the device

device.Initialize();

//Tell the world what we’re about to do.

cout!! ‘‘Running a cycle on ’’ !!

device.GetName();

//Away we go!

device.Run();

}

上面的代码段显示了如何 IDevice 接口可用于一般控制设备。如果 GetDevice 驱动程序返回 CSealer 对象的引用，DoSomeWork 将控制密封件。如果 GetDeviceDriver 返回的引用到移液器，DoSomeWork 将控制移液器。虽然这是规模的一个简化的例子，是规模的简单直观，想象一下如何使用接口和多态性导致伟大控制器软件开发中经济。

沿 IDevice 的一样，可以生成附加接口。例如，也许称为专题讨论会的接口可用于促进通信和 LIMS。

聪明的读者会注意到任何第三方可以开发驱动程序，只需通过实现 IDevice 接口的索赔略有瑕疵。问题是任何驱动程序用户写道，像 CSealer，将不得不直接挂钩，用于控制软件可执行文件。通过大量的现有技术，包括微软的 COM 解决此问题或。NET，或 CORBA。所有这些技术使最终用户可以在运行时（而不是在设计时链接的独立组件中实现抽象接口。细节会超出了本文的范围。

指导教师审阅意见：

指导教师：

年月日