外文原文及译文

北京联合大学毕业设计（论文）外文原文及译文

题目：中国移动业务管理系统

专业：计算机科学与技术指导教师：商新娜

学院：信息学院学号： 2009080405108

班级： 20090804051 姓名：宋晶

一、外文原文

Selecting the Right Platform Components

Every software developer needs to be able to make decisions. Software development involves decision making, from deciding on the right programming language to use to selecting the developer tools, or deciding on how best to deploy and distribute an application. This chapter introduces the process that we will use throughout the rest of the book for selecting components for our enterprise platform.

Decisions, Decisions, Decisions

As we discuss in Chapter 1, the focus of this book is on building an enterprise software platform. As demonstrated in that chapter, an enterprise platform comprises a large number of independent components, each of which contributes capabilities to the overall platform. Selecting the components to be used to establish a platform is typically the role of a software architect. The architect uses his or her knowledge of the system to be delivered and the needs of the stakeholders to help make choices about which components to use. The architect must be able to explain the choices to others, such as programmers, customers, and management, in order to achieve the acceptance needed to make the project a successful one.

As software architects, we need to select which components will compose our enterprise platform. For example, if you know that the applications that will be created for this platform will use a Web-based interface, you will want to make sure that you have a servlet container as one of the platform components.After you determine the need for a servlet container, you need to decide among the many choices of servlet containers.

There may be a wide variety of choices for any single component in your

platform. Because you have a large number of components that can be applied to your architecture, you want to make sure that you have a consistent means of deciding which component implementation you will select and use, and then be able to communicate the reasons for your choices to other stakeholders in the project. A consistent and documented product-selection process eases this communication task by making it possible to explain to all involved parties how the decision to use a specific component was reached.

This decision-making process is not unique to the use of open source software,

but applies to the selection of any software component or application.However, this book is primarily about using open source software, so the first decision we will examine is the decision to use open source software.

Choosing Open Source Software

Why choose to use open source software? Although this question may offend

some open source zealots, open source software is not the right choice in every

situation. It is good to know when open source software is the right choice and be able to defend the decision to other stakeholders in a project. So, in this light, let’s examine why people choose to use—or not use—open source solutions.

So what are the factors that push companies to choose the open source alternative to commercial software? How does open source software compare to

commercial software in the areas of cost, fitness, quality, risk, and time? When you are making a decision to purchase or use any product, there several things of interest to consider:

■ Cost

■ Suitability

■ Quality

■ Risk

■ Time

Weigh the needs and features of your product against each of these points

when making a product decision. In some cases, cost may be the driving factor

in making a product decision; in others cases, it may be suitability, quality, level of risk, or time. The following sections examine each of these factors briefly to help you understand how they affect a project decision.

Cost

Cost reflects the entire cost of owning and using the software. This is much

more than just the initial cost of purchase. Cost includes cost of acquisition, cost of use, cost of training, and cost of maintenance. Taking all these costs into

account, you come up with what’s called the total cost of ownership for the time

that the product wil l be used. Cost applies directly to a project’s budget, and so

in general we want to minimize costs when possible.

During the height of the “dot-com” era, Linux was heralded by many as the

choice operating system for many of the newly formed and cash-tight startup companies. The rationale was simple, Linux met the software needs of these companies and could be acquired for free. In these cases, the initial cost of product acquisition was a driving factor in the decision-making process.

Most open source software is available for free. There may be restrictions

placed on how the software or resulting products are used commercially, but the software is typically free of acquisition costs. That is not to say that there are no costs involved in using open source software, but the initial cost of purchase

is zero.

Let’s examine these costs as they relate to open source software. The cost of

purchase is, of course, zero. There are, however, costs associated with: Training. Initially, the cost of training for an open source application is

likely to be higher than for commercial applications. This is because

often there are limited training resources specializing in providing training

for open source applications. However, for a large organization with

many users, an initial investment in the development of training materials may be less costly than the purchase cost of the alternative commercial software.

Operations. It is difficult to determine operational cost differences. Initially, any new software will have higher costs associated with operations

as the staff becomes more familiar with the software and the way it can

be configured and used. Commercial products often offer or work with

add-on tools (such as monitoring programs) that can be used to reduce operational costs. These tools often support open source products as well.

For example, Apache is well supported by third-party Web monitoring tools. In general, the operational costs of open source software should not

be substantially different from those of commercial equivalents. Maintenance.

Commercial software products normally charge annual

fees to cover maintenance of the software and provide regular updates. Active open source projects maintain the software and provide updates

for free. If a company wants to pay a fee for software maintenance, most open source products have developers who are willing to accept the

money and address company-specific problems.

To summarize, open source software wins on initial acquisition costs, but loses on training costs. It ties with commercial software on operational costs but wins on maintenance costs. Overall, in most cases open source software will be less expensive for companies to use.

Suitability

Suitability is the measure of how well suited a given product is to the requirements

that it is being applied against. In general, you want the product that best satisfies your project’s needs.

As long as we are focused on enterprise Java and we select components that

conform to the standards, we know that we have achieved a certain amount of suitability for our purpose of building an enterprise platform. Suitability has to be measured against each project’s individual needs.iang As a very basic example,

if you want to pound a nail into a board, you don’t use a pot, you use a

ham mer. If you’re making soup, though, a hammer will do you no good at all, but a pot will be quite useful.

For a platform developer, suitability is normally based on product features

that relate to conformance to standards and performance metrics. If the primary

purpose is to use the open source platform as a development environment and deployment will be done on a different platform, then most performance considerations typically do not apply.

Quality

Obviously, the higher the quality of your chosen software, the better. There are

three major quality concerns you need to consider when evaluating software: robustness, reliability, and reparability. These concerns are discussed in detail in the following sections.

Robustness

Robustness is a measure of how well a product withstands abnormal situations.

Sure, we’ve established that open source software is typically zero initial

cost and subsequently fast to acquire. But does it follow, as the saying goes,. “You get what you pay for”? In other words, can we expect low quality from free software just because we pay nothing for it? The answer is that quality is just as much an issue with open source software as it is with commercial software,

and that the money you pay for a given piece of software does not in any

way determine its quality.

Reliability

Reliability is a measure of how often the product breaks. First, the source code

of an open source product is open to scrutiny. Many people can review and comment on the source code. You can even review the source code for a product

before you decide to use it. Because of this, developers are often able to

offer fixes as software problems are found. This means that many times problems

are found and fixed faster in open source programs. It also means that, if needed, you can fix the software yourself.

Now, compare this to the commercial software. The software is reviewed internally by the vendor and depends on the quality assurance (QA) process within the vendor. In this model, with many fewer people testing the software, bugs may or may not be caught, just as with open source software. The difference

is that the eyes that are looking over the code are those of the QA employees of the company that makes the software; with open source software, the reviewers are typically those who are using the software. If a bug does make it

into a release, the size of the vendor’s available workforce limits its ability to fix the bug and make the fix available to the user community. This means that a typical vendor has to decide which bugs to fix and which ones to ignore or postpone fixing until a later release. Even worse, the vendor may decide to no longer support a particular version of the software, and a fix may never be released or you may be forced to upgrade the software to a newer release. Microsoft, for example, collects all fixes (in particular those that don’t have to do with security) into yearly releases called service packs, meaning that if you find a bug in Windows you may well have to wait up to a year to get the fix, if not longer. Or, sometimes the company will fix the bug in a new release of Windows, forcing you to pay for the upgrade if you want to get a fix for a problem

you had with a previous release.

Reparability

Reparability is a measure of how long it takes to repair a product once it is broken. In general, open source software is more repairable because the source

code is available, and this property typically means that bugs have often been discovered and repaired before you encounter them.

As you can see, open source products can have some advantages over typical commercial software products. The bottom line is that any particular open source product may or may not have a quality advantage over any specific commercial product. In many cases, the quality of open source products is at least comparable to that of their commercial counterparts. Often, it is superior. The issue is not black and white; you have to judge each piece of software on its own merits against its competition to determine the quality of that software, regardless of how much it costs to acquire.

二、译文

选择正确的平台组件

每个软件开发人员都需要能够有作出决定的能力。软件开发就涉及到做决定，从正确的编程语言到决定使用选择开发的工具，或是就如何最好地部署和分配应用程序的决定。本章我们将介绍为企业平台选择组件。

决定，决定，决定

正如我们在第一章中的讨论，本书的重点是建立企业的软件平台。正如该章表明，一个企业平台包括多个独立组件，每个组件都对所有的平台有一定的贡献。选择的组件将用于建立一个平台，这个通常是一个软件架构师的角色。建筑师用自己的知识为那些存在利益关系者们决定选择使用哪些组件。建筑师一定能向别人解释他选择的原因，就像程序员，客户和管理等，都是为了作出一个成功的项目。

作为软件设计师，我们需要确定选择哪些组件将会组成我们的企业平台。例如，如果你知道一个应用程序，它创建这个平台将使用一个基于网络的界面，你会希望确保作为该平台的组件之一的servlet容器。当你确定需要这个servlet容器时，你需要选择的servlet容器中的许多选项。

对于平台上单一的组件可能会有很多大量的选择。因为你的架构有很多组件能应用到，你要确保你有一个一致的方式决定组件的实现以及选择和使用，然后可以将您在该项目中选择的原因传达给其他的利益相关者。一致并记录产品的选择过程就很容易地解释涉及到决定用特殊组件的部分。

这一决定过程不是只能选择使用开放源码软件，但是要适用于任何软件的组件或应用程序的选择。然而，这本书主要是关于使用开放源码软件，所以首先，我们将研究使用开放源码软件。

选择开放源码软件

为什么要选择使用开源软件？当然，这个问题可能会冒犯一些开源狂热者，开源软件不是在任何情况下都是正确的选择。知道什么时候开放源码软件是正确的选择，并能够保护一个项目的其他利益相关者从中的决定。所以，从这个角度，让我们看看人们为什么选择使用或不使用开源的解决方案

那么是什么因素促使公司选择开源软件来替代商业软件？如何比较开放源码软件和商业软件在成本，适宜，质量，风险，时间上的区别，当你作出决定购买或使用任何产品，就会愿意考虑一下几件事情：

■成本

■适宜性

■质量

■风险

■时间

当决定购买某个产品时，要权衡需求以及以上几点考虑的事情。在某些情况下，成本可能是决定购买产品的驱动因素，在其他情况下，再考虑适宜性，质量，风险，或时间的因素。以下各节简单探讨这些因素，帮助您了解它们如何决定影响一个项目。

成本：

成本反映了拥有和使用该软件的全部费用。这比最初购买成本的花费多的多。成本包括购买成本，使用成本，培训成本和维护成本。考虑到所有这些费用，你会想出该产品将会花费的总成本时间。费用可直接适用于一个项目的预算，所以我们一般要尽可能降低成本

在高速提倡“dot-com”的时代，Linux成为了作为新成立以及现金紧张的创业公司在很多情况下选择的操作系统。其理由很简单，Linux需要的软件满足这些公司的需求，即可以免费获得使用。在这种情况下，产品收购的初始成本是在决策过程的

驱动因素：

大部分开源软件是免费的。这就可能限制了软件或产品的商业用途定位，但软件的收购成本通常是免费。这并不是说，使用开放源码软件就不会涉及任何费用，但购买的初始成本是零。

让我们来看看关系到这些开放源码软件的费用。当然，购买成本是零。然而这些费用关系到：

训练：

首先，培训制作一个开源应用成本很可能比用于商业应用的高。这是因为经常有有限的培训资源来为开源应用做专业的培训。然而，对于一个拥有众多用户的大团体，在培训的开发初期的投资可能会低于其他商业软件的购买成本。

运营：

确定运营成本的差异是很困难的。起初，任何新的软件与其运营相关的费用都是较高的。这是因为员工通过这种方法可以越来越熟悉，对其进行认证并且使用它。商业产品通常提供或使用附加工具（如监测方案），可以用来降低运营成本。这些工具通常也支持开源产品。例如，Apache就是很好的第三方网络监控工具。一般来说，开源软件的运营成本大体上不应该与商业软件等值。

维护：

商业软件产品通常收取年费以保证软件维护和提供定期的更新。免费提供活跃的开源项目维护软件和升级。如果一家公司想要支付费用来进行软件维护，许多的发开开放源码产品的人都愿意接受这笔钱来解决公司的具体问题。

总之，开源软件胜在初始采购成本，但是失败在培训费用。它关系着商业软件的营运费用确获利在维护费用上面。总体而言，在大多数情况下，开源软件对于公司的使用更加便宜一些。

适用性：

适用性是如何满足一个给定的被应用的产品的需求。在一般情况下，你最想产品满足项目的需要。

我们在专注于企业Java组件或者选择符合标准的组建时，我们知道，我们都已经达到我们的目的，就是建立一个一定的数额的，具有一定适应性的企业平台。适宜性，必须衡量针对每个项目的各性化的需求。就像一个非常简单的例子，如果你想把一个钉子订到木板上，你不使用一个锅，你用锤子。如果你正在做的汤，当然，锤子对你就一点用都没有了，但锅就会相当的有用。

对于一个平台的开发，适用性通常是根据产品的特点普遍符合相关的标准和性能的指标。如果主要目的是利用开源的平台在不同的平台上完成开发环境和部署，那么

大多数性能上的考虑通常是不适用的。如果开源组件将被部署使用，那么该平台的适用性需要对部署的要求和比较竞争产品进行评估，以确定最佳的部署解决方案。

质量：

很明显，选择质量越好的软件越好。但是当你评价一个软件时，要考虑有三个主要的质量问题：耐用性，可靠性和可维修性。这些问题将在以下各章中进行详细讨论。耐用性：

耐用性是测试一个产品在抵抗不正常状态下保持良好运行的一个方法。当然，我们已经建立了通常是零成本的开放源码软件，随后并快速获取。但这是否遵循就像俗话说的那样“有付出就有回报”？换言之，我们降低要求使用免费软件，只是因为我们不用付钱吗？答案是质量仅仅是关于开放源码软件的问题。就像商业软件，你交付了钱获得的软件同样不能保证质量一样。

可靠性：

可靠性是检测该产品多久坏一次的方法。首先，开源产品的源代码是仔细观察过的。许多人可以审查和评论的源代码。你甚至可以检验产品的源代码，然后再决定是否使用它。正因为如此，开发商往往能够提供的软件出现问题时的修补程序。这意味着，很多时候，开放源码问题的发现后修复会很快。这也意味着，如果需要，你可以修复自己的软件。

现在，来比较它与商业软件。该软件是由供应商内部审查并依赖于供应商的质量保证（QA）。在此模型中，测试软件的人少，错误可能被捕捉，就如同开放源码软件。所不同的是，质量保证员工的眼睛都在看代码来做软件;而开放源码软件通常是看谁正在使用该软件。如果确定它是一个错误，供应商限制该公司现有员工解决该问题，并提供修复给用户群体。这意味着，一个典型的供应商必须决定有哪些错误修复，哪些忽视或推迟到以后的版本修复。更糟的是，供应商可能会决定不再支持该软件的特殊版本，以及一个修复程序可能不会被批准，或者您可能被迫软件升级到较新版本。例如，微软，收集所有修复（特别是那些没有与安全性的）每年淘汰的所谓的服务包，这意味着如果你找到一个Windows系统的错误可能要等上一年的时间来修复程序，甚至更长时间。或者，公司会修复Windows新版本的错误，迫使你升级系统，如果你想解决一个问题，你就得使用最新的版本。

维修性：

维修性是看当产品被毁坏的时候需要多长时间来修复。一般来说，开源软件是能补救的，因为源代码是可得到的。这个典型的特点通常意味着在你遇到它们之前，错误往往会被发现并修复。

正如你可以看到，开源产品可以拥有典型的商用软件产品的一些优点。底线是任

何特殊的开源产品可能会比任何具体的商业产品质量好。在许多情况下，开源产品的质量至少相当于其商业同行。通常，它是优越的。这个问题不像黑色和白色，让你必须判断每个软件本身的优点来定义该软件的质量，无论多少它需要多少成本。