面向对象软件构造(第2版)-第1章 软件品质

Engineering seeks quality; software engineering is the production of quality software. This book introduces a set of techniques which hold the potential for remarkable improvements in the quality of software products.

工程学探索品质；软件工程是高品质软件的成果.本书介绍了一系列可以显著提高软件产品品质的技术.

 

 

Before studying these techniques, we must clarify their goals. Software quality is best described as a combination of several factors. This chapter analyzes some of these factors, shows where improvements are most sorely needed, and points to the directions where we shall be looking for solutions in the rest of our journey.

在学习这些技术之前,我们要清楚它们的目标. 软件品质是一些因数组合的最佳描述. 这章分析其中的一些因数，描述了最强烈需要提高品质的地方,并指出那些在余下的过程中我们将要寻找的解决方案的方向.

 

 

 

 

1.1 EXTERNAL AND INTERNAL FACTORS

1.1 外部和内在的因数

 

 

We all want our software systems to be fast, reliable, easy to use, readable, modular, structured and so on. But these adjectives describe two different sorts of qualities. On one side, we are considering such qualities as speed or ease of use, whose presence or absence in a software product may be detected by its users. These properties may be called external quality factors.

我们都希望我们的软件系统是快速的,可靠的,易用的,可读的,模块的,结构化等等.但是这些形容词描述了二类不同的品质.一方面,我们会考虑用户能感觉到的品质.诸如使用的速度或易用性.这些特性被称为外部品质因数。

 

 

Under “users” we should include not only the people who actually interact with the final products, like an airline agent using a flight reservation system, but also those who purchase the software or contract out its development, like an airline executive in charge of acquiring or commissioning flight reservation systems. So a property such as the ease with which the software may be adapted to changes of specifications — defined later in this discussion as extendibility — falls into the category of external factors even though it may not be of immediate interest to such “end users” as the reservations agent.

关于"用户",我们不但应该包括实际使用最终产品的人,像一个使用班机预订系统的航空公司代理商, 也应该包括那些软件购买者或外包开发者,如一个掌管班机预订系统分配权的航空公司主管.因此,一种如易于改编软件以适应变化规格的特性--稍后作为扩充性详细说明--即使它不可能象预订代理商那样的"最终用户"立刻产生兴趣, 但也归属于外部因数的一种.

 

 

Other qualities applicable to a software product, such as being modular, or readable, are internal factors, perceptible only to computer professionals who have access to the actual software text.

其它的可以应用在软件产品中的品质,如模快化或可读的,都是内在因数,只有那些接触到软件程序的计算机专业人士才察觉的到.

 

 

In the end, only external factors matter. If I use a Web browser or live near a computer-controlled nuclear plant, little do I care whether the source program is readable or modular if graphics take ages to load, or if a wrong input blows up the plant. But the key to achieving these external factors is in the internal ones: for the users to enjoy the visible qualities, the designers and implementers must have applied internal techniques that will ensure the hidden qualities.

最后,只有外部因数才是要紧的.假如我在使用一个WEB浏览器或生活在一个计算机控制的核子植物旁,在图形载入太慢或一个错误的输入炸毁植物的情况下,我并不是太在意源程序是可读的或模块化的.但是实现这些外部因数的关键却存在于内在因数之中:对于用户感兴趣的看得到的品质,设计者和实现者必须提供内在的技术,这些技术能确保这些隐藏的品质.

 

 

The following chapters present of a set of modern techniques for obtaining internal quality. We should not, however, lose track of the global picture; the internal techniques are not an end in themselves, but a means to reach external software qualities. So we must start by looking at external factors. The rest of this chapter examines them.

下一小节描述了一系列获得内在品质的时新技术.然而,我们不应该丢掉全局观念;内在的技术并不是自我终结,而是一个达到外部的软件品质的手段.因此我们必须先开始着眼于外部因数.下面研究他们.

 

 

 

 

1.2 A REVIEW OF EXTERNAL FACTORS

1.2 外部因数介绍

 

 

Here are the most important external quality factors, whose pursuit is the central task of object-oriented software construction.

这些是最重要的外部品质因数, 其活动就是面向对象软件构造的核心任务.

 

 

Correctness

Definition: correctness Correctness is the ability of software products to perform their exact tasks, as defined by their specification. 正确性是指软件能完成如文档所定义确切的工作的能力.

正确性

 

 

Correctness is the prime quality. If a system does not do what it is supposed to do, everything else about it — whether it is fast, has a nice user interface¼ — matters little.

正确性是首要的品质.如果一个系统不做它应该做的,其它的一切--是否它是快速的,是否它有良好的用户界面--都无关紧要.

 

 

But this is easier said than done. Even the first step to correctness is already difficult: we must be able to specify the system requirements in a precise form, by itself quite a challenging task.

但这易说难做.甚至一开始,正确性就已经遇到了麻烦:我们必须能够以一种精确的形式叙述系统需求,这本身就是一项挑战性的任务。

 

 

Methods for ensuring correctness will usually be conditional. A serious software system, even a small one by today’s standards, touches on so many areas that it would be impossible to guarantee its correctness by dealing with all components and properties on

a single level. Instead, a layered approach is necessary, each layer relying on lower ones:

确保正确性的方法通常是有条件的.一个完整的软件系统,更甚至以今天标准来看一个小型的软件系统,涉及到如此众多的区域,以致于它不可能在一个单一层次处理所有的组件和特性来保证它的正确性.相反的,分层的方式是必需的,每个层次依赖于较低的一层:

 
Application system
In the conditional approach to correctness, we only worry about guaranteeing that each layer is correct on the assumption that the lower levels are correct. This is the only realistic technique, as it achieves separation of concerns and lets us concentrate at each stage on a limited set of problems. You cannot usefully check that a program in a high level language X is correct unless you are able to assume that the compiler on hand implements X correctly. This does not necessarily mean that you trust the compiler blindly, simply that you separate the two components of the problem: compiler correctness, and correctness of your program relative to the language’s semantics.

在达到正确性的条件中,我们只关心每个层次的正确性保证,这是假设在较低的层次正确的基础上的. 这只是现实的技术,它完成关系分离,并且让我们把有限的问题集中在一个层次上. 你不能有效地检查在高级语言X中的一个程序是否正确，除非你能够假定在手上的编译器能正确地实现X.这并不是必须叫你盲目地信赖编译器,只不过让你把问题分成二个方面: 编译器正确性,和你程序所用语言的语意正确性.

 

 

In the method described in this book, even more layers intervene: software development will rely on libraries of reusable components, which may be used in many different applications.

在本书描述的方法中,涉及了较多的层次: 软件开发将会依赖可复用组件库,这些库可以被用于多种不同的应用程序中.

The conditional approach will also apply here: we should ensure that the libraries are correct and, separately, that the application is correct assuming the libraries are.

有条件的方式也将会在这里应用: 我们应该确定库是正确的和分离的,应用程序是正确的并假定库也是.

 

 

Many practitioners, when presented with the issue of software correctness, think about testing and debugging. We can be more ambitious: in later chapters we will explore a number of techniques, in particular typing and assertions, meant to help build software that is correct from the start — rather than debugging it into correctness. Debugging and testing remain indispensable, of course, as a means of double-checking the result.

许多专业人员, 一要呈现软件的正确性,就会想到测试和除错.我们要能更进一步:在后面的章节中,我们将会探究一系列的技术,特别是类型和断言,来帮助你建立从开始就正确的软件--胜于为正确而除错.当然,除错和测试作为重复检查结果的方法仍旧是不可缺少的.

 

 

It is possible to go further and take a completely formal approach to software construction. This book falls short of such a goal, as suggested by the somewhat timid terms “check”, “guarantee” and “ensure” used above in preference to the word “prove”. Yet many of the techniques described in later chapters come directly from the work on mathematical techniques for formal program specification and verification, and go a long way towards ensuring the correctness ideal.

有可能的话需进一步采取一种完整地形式去讨论软件构造. 本书达不到如此目标,只能用些弱小的术语,如"检查","保证"和"确保",去替代”证明”这样的词语.仍有许多在稍后描述的技术,直接地来自工作,这些工作用数学技术产生正式的程序规格和确认书.这些技术有助于确保正确性。

 

 

Robustness

健壮性

健壮性

Definition: robustness

Robustness is the ability of software systems to react appropriately to abnormal conditions.

健壮性是软件系统在非正常条件下正确反应的能力.

Robustness complements correctness. Correctness addresses the behavior of a system in cases covered by its specification; robustness characterizes what happens outside of that specification.

健壮性与正确性互补.正确性处理规格所涵盖的系统行为.健壮性则表现在规格之外.

 

 

As reflected by the wording of its definition, robustness is by nature a more fuzzy notion than correctness. Since we are concerned here with cases not covered by the specification, it is not possible to say, as with correctness, that the system should “perform its tasks” in such a case; were these tasks known, the abnormal case would become part of the specification and we would be back in the province of correctness.

如它的字面定义所述, 健壮性天生是一个比正确性模糊的概念.由于我们关心的情况并没有被规格所涵盖,所以不可能说,和正确性一样,系统应该在这样的情况下”完成它的任务”;如果事先知道,这些反常的情况将会变成规格的一部份,这又将回到正确性的范围了.

 

 

This definition of “abnormal case” will be useful again when we study exception handling. It implies that the notions of normal and abnormal case are always relative to a certain specification; an abnormal case is simply a case that is not covered by the specification. If you widen the specification, cases that used to be abnormal become normal — even if they correspond to events such as erroneous user input that you would prefer not to happen. “ Normal” in this sense does not mean “desirable”, but simply “planned for in the design of the software”. Although it may seem paradoxical at first that erroneous input should be called a normal case, any other approach would have to rely on subjective criteria, and so would be useless.

当我们学习异常处理的时候,反常情况的定义将会再次用到.它意味着正常和反常情况的观念总是相对于特定的规格;一个反常情况仅仅只是一个不是被规格所涵盖的事件.如果你放宽规格,反常情况就变成了正常的--即使他们符合某种事件,像是一个你不希望发生的错误的用户输入.这种情况下,”正常”并不意谓”适当”,只是仅仅”在软件的设计中规划好的”. 虽然起先错误的输入认为是正常的情况,这看上去是荒谬的,但是任何其它的方法会不得不依赖主观的标准,同样都是无用的.

 

 

There will always be cases that the specification does not explicitly address. The role of the robustness requirement is to make sure that if such cases do arise, the system does not cause catastrophic events; it should produce appropriate error messages, terminate its execution cleanly, or enter a so-called “graceful degradation” mode.

总会有一些规格不能明确地处理的情况.健壮性需求的作用就是确保如此的情况出现时系统不会引发灾难；它应该生产适当的错误信息,结束运行,或进入一个所谓的安全模式的运行。

 

 

Extendibility

Definition: extendibility Extendibility is the ease of adapting software products to changes of specification. 扩充性是指易于修改软件以适应规格变化.

扩充性

扩充性

Software is supposed to be soft, and indeed is in principle; nothing can be easier than to change a program if you have access to its source code. Just use your favorite text editor.

软件应该是软的,大体上没错;如果你能存取它的源代码,就觉得没有什么比改变一个程序更容易.这仅仅使用你的喜爱文字编辑器而已.

 

 

The problem of extendibility is one of scale. For small programs change is usually not a difficult issue; but as software grows bigger, it becomes harder and harder to adapt. A large software system often looks to its maintainers as a giant house of cards in which pulling out any one element might cause the whole edifice to collapse.

扩充性的问题是衡量标准之一.对于小的程序而言变化通常不是一个困难的议题；但是当软件变得比较大的时,它变成越来越难以修改.维护者通常把一个大的软件系统看成如一个庞大的用纸牌搭成的房子,抽出任何一张都可能引起整个的大厦崩溃.

 

 

We need extendibility because at the basis of all software lies some human phenomenon and hence fickleness. The obvious case of business software (“Management Information Systems”), where passage of a law or a company’s acquisition may suddenly invalidate the assumptions on which a system rested, is not special; even in scientific computation, where we may expect the laws of physics to stay in place from one month to the next, our way of understanding and modeling physical systems will change.

我们需要扩充性是因为在所有的软件基础上存在一些人类主观现象上,并因此变幻无常. 明显的例子是商业软件(“信息管理系统”),一段法律或公司的收益可能突然使系统所依赖的假设无效,这很常见;甚至,在我们认为自然法则恒定不变的科学计算中,我们对实际系统所能理解和建模的方法也会改变.

 

 

Traditional approaches to software engineering did not take enough account of