面向对象软件构造(第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 change, relying instead on an ideal view of the software lifecycle where an initial analysis stage freezes the requirements, the rest of the process being devoted to designing and building a solution. This is understandable: the first task in the progress of the discipline was to develop sound techniques for stating and solving fixed problems, before we could worry about what to do if the problem changes while someone is busy solving it. But now with the basic software engineering techniques in place it has become essential to recognize and address this central issue. Change is pervasive in software development: change of requirements, of our understanding of the requirements, of algorithms, of data representation, of implementation techniques. Support for change is a basic goal of object technology and a running theme through this book.
传统的软件工程方法没有充分考虑变化,而是依赖软件生命周期的理想的观点,即分析的开始阶段,需求就已经冻结了,其余的过程则投入到设计和构建方案中.这是可以理解的:如果当人们在忙于解决问题的同时,问题却又改变了,我们会担心到底应该做什么.在这之前,学科发展中的第一个阶段是要为陈述和解决要修改的问题开发合理的技术.但是现在随着基本软件工程技术的就绪,在认知和处理这个中心议题时,它已经变得不可或缺.在软件发展中变化是普遍的: 需求的变化,我们需求理解的变化,运算法则的变化,数据表示的变化,技术实施的变化.在本书中,支持变化是对象技术的一个基本目标和一个持续的主题。
Although many of the techniques that improve extendibility may be introduced on small examples or in introductory courses, their relevance only becomes clear for larger projects. Two principles are essential for improving extendibility:
虽然许多改良扩充性的技术可能在小的例子上或在介绍性的课程中被介绍，但是它们在大的项目中才更清晰,下面是二项改良扩充性的要点:
• Design simplicity: a simple architecture will always be easier to adapt to changes than a complex one.
设计单纯: 一个简单的架构总是比复杂的更容易适应变化.
• Decentralization: the more autonomous the modules, the higher the likelihood that a simple change will affect just one module, or a small number of modules, rather than triggering off a chain reaction of changes over the whole system.
分散性:更独立的模块,更好地可能性是一个简单的变化只是影响一个模块,或很少的模块,胜于触发在整个的系统上的连锁反应。
The object-oriented method is, before anything else, a system architecture method which helps designers produce systems whose structure remains both simple (even for large systems) and decentralized. Simplicity and decentralization will be recurring themes in the discussions leading to object-oriented principles in the following chapters.
在其它方法之前,面向对象的方法是一个帮助设计者产生系统结构的方法,来保持系统简单性(甚至是为大系统)和分散性. 在下面的章节中,单纯性和分散性还会在对面向对象的原则讨论中再次作为主题。
Reusability
Definition: reusability
Reusability is the ability of software elements to serve for the construction of many different applications.
复用性是软件元件能在不同的应用架构中使用的能力.
复用性
复用性
The need for reusability comes from the observation that software systems often follow similar patterns; it should be possible to exploit this commonality and avoid reinventing solutions to problems that have been encountered before. By capturing such a pattern, a reusable software element will be applicable to many different developments.
对复用性的需要来自于软件系统时常有相似模式的观查;开发应该是尽可能的利用共通性,避免重复对之前已经遇到的问题的解决办法.达到如此的模式,一个可复用的软件元件就可以应用在许多不同的开发中.
Reusability has an influence on all other aspects of software quality, for solving the reusability problem essentially means that less software must be written, and hence that more effort may be devoted (for the same total cost) to improving the other factors, such as correctness and robustness.
复用性对软件品质的所有其它的方面有着影响力,本质上解决复用性问题意味着只需写少量的软件.因此较多的努力可以投入到改良其它的因数方面,如正确性和健壮性。
Here again is an issue that the traditional view of the software lifecycle had not properly recognized, and for the same historical reason: you must find ways to solve one problem before you worry about applying the solution to other problems. But with the growth of software and its attempts to become a true industry the need for reusability has become a pressing concern.
这里还有一个议题是软件生命周期的传统看法没有完全地得到验证,为了相同的历史理由: 在你担心把方案应用于其它的问题之前,你必须找到方法去解决某个问题. 但随着软件的增长,并要转变成真正的工业化,复用性的需要已经变得至关重要.
Reusability will play a central role in the discussions of the following chapters, one of which is in fact devoted entirely to an in-depth examination of this quality factor, its concrete benefits, and the issues it raises.
在下列各章的讨论中,复用性将会扮演一个核心的角色, 其中有一章贡献了完整的篇幅完整细致地分析了这个品质因数,和它具体的优点,并进一步深入下去.
Compatibility
兼容性
Definition: compatibility
Compatibility is the ease of combining software elements with others.
兼容性是指软件元件易于和其他部件结合.
Compatibility is important because we do not develop software elements in a vacuum: they need to interact with each other. But they too often have trouble interacting because they make conflicting assumptions about the rest of the world. An example is the wide variety of incompatible file formats supported by many operating systems. A program can directly use another’s result as input only if the file formats are compatible.
兼容性之所以重要是因为我们并不是在真空的状态下开发软件元件:他们彼此互动. 但他们经常在互动方面存在障碍因为他们在许多领域制造着冲突的迹象.许多操作系统不兼容广泛多样的文件格式,就是一个例子. 只要文件格式是兼容的,程序就能直接地使用其它的结果作为输入.
Lack of compatibility can yield disaster. Here is an extreme case:
缺乏兼容性能带来灾难. 这里有一个极端的例子:
DALLAS — Last week, AMR, the parent company of American Airlines, Inc., said it fell on its sword trying to develop a state-of-the-art, industry-wide system that could also handle car and hotel reservations.
AMR cut off development of its new Confirm reservation system only weeks after it was supposed to start taking care of transactions for partners Budget Rent-A-Car, Hilton Hotels Corp. and Marriott Corp. Suspension of the $125 million, 4-year-old project translated into a $165 million pre-tax charge against AMR’s earnings and fractured the company’s reputation as a pacesetter in travel technology. [¼]
As far back as January, the leaders of Confirm discovered that the labors of more than 200 programmers, systems analysts and engineers had apparently been for naught. The main pieces of the massive project — requiring 47,000 pages to describe — had been developed separately, by different methods. When put together, they did not work with each other. When the developers attempted to plug the parts together, they could not. Different “modules” could not pull the information needed from the other side of the
bridge.
AMR Information Services fired eight senior project members, including the team leader.
[¼] In late June, Budget and Hilton said they were dropping out.
达拉斯--上星期,美国航空公司的母公司AMR说它试图开发一个系统失败了,此系统是高水准和工业化的系统,它也可以处理汽车和旅馆预订.
在期待它开始为合伙人Budget Rent-A-Car, Hilton Hotels公司和Marriott公司处理交易的仅仅几个星期后,AMR终止了新的CONFIRM预订系统的开发,一亿二千五百万美元和四年时间项目的暂停,变成了一亿六千五百万美元的税前花费,并且断送了公司作为旅行业先驱的名誉.
早在一月份, CONFIRM系统的主管,发现了超过200名程序员,系统分析员和工程师的劳动成果变成了零.庞大的项目中主要的一块--需要描述47,000个页面--用不同的方法各自开发.当整合时却不能彼此工作.当开发者尝试整合部份在一起时,他们失败了.不同的"模块"不可以在两端通讯.
AMR信息服务部解雇了八个高级项目成员,其中包括主管.在六月下旬,Budget和Hilton公司退出了.
The key to compatibility lies in homogeneity of design, and in agreeing on standardized conventions for inter-program communication. Approaches include:
兼容性的关键是和设计同质的,并和交互程序通讯协定的标准一致.步骤包括:
• Standardized file formats, as in the Unix system, where every text file is simply a sequence of characters.
标准化文件格式,如同在Unix系统中,每个文本文件只是一个字符流.
• Standardized data structures, as in Lisp systems, where all data, and programs as well, are represented by binary trees (called lists in Lisp).
标准化数据格式,如同在Lisp系统中,所有的数据和程序都表现为二进制树(在Lisp中称为列表).
• Standardized user interfaces, as on various versions of Windows, OS/2 and MacOS, where all tools rely on a single paradigm for communication with the user, based on standard components such as windows, icons, menus etc.
标准化用户界面,同样地在Windows,OS/2和MacOS 的各种不同版本上,所有的工具建立于和用户交互的专一模板上,并基于标准组件,像是视窗,图像,及菜单.
More general solutions are obtained by defining standardized access protocols to all important entities manipulated by the software. This is the idea behind abstract data types and the object-oriented approach, as well as so-called middleware protocols such as
CORBA and Microsoft’s OLE-COM (ActiveX).
对所有软件操纵的重要实体定义标准化存取协议,是更通用的解决方案. 这是抽象数据类型和面向对象方式之后的概念,又称之为中间件协定,如CORBA和微软公司的OLE-COM(ActiveX).
Efficiency
Definition: efficiency
Efficiency is the ability of a software system to place as few demands as possible on hardware resources, such as processor time, space occupied in internal and external memories, bandwidth used in communication devices.
高效性是软件系统尽可能少的占用硬件资源的能力,像是处理器时间,内在的和外部内存空间占用，通信装置的带宽.
高效性(效率)
高效性(效率)
Almost synonymous with efficiency is the word “performance”. The software community shows two typical attitudes towards efficiency:
“性能”’几乎是效率的同义字.软件团体对于效率有两种典型的态度:
• Some developers have an obsession with performance issues, leading them to devote a lot of efforts to presumed optimizations.
一些开发者固执于性能,导致他们投入了许多努力于假定的优化。
• But a general tendency also exists to downplay efficiency concerns, as evidenced by such industry lore as “make it right before you make it fast” and “next year’s computer model is going to be 50% faster anyway”.
但是一般的趋向也存在不重视性能考虑, 如工业定律所证实的那样: “先对再快”’和”下一年计算机模型会增长50%的性能”.
It is not uncommon to see the same person displaying these two attitudes at different times, as in a software case of split personality (Dr. Abstract and Mr. Microsecond).
同一个人在不同时候显示这两种态度是很寻常的, 就象在一个软件中有不同的个性一样.(抽象博士和微秒先生)
Where is the truth? Clearly, developers have often shown an exaggerated concern for micro-optimization. As already noted, efficiency does not matter much if the software is not correct (suggesting a new dictum, “do not worry how fast it is unless it is also right”, close to the previous one but not quite the same). More generally, the concern for efficiency must be balanced with other goals such as extendibility and reusability; extreme optimizations may make the software so specialized as to be unfit for change and reuse. Furthermore, the ever growing power of computer hardware does allow us to have a more relaxed attitude about gaining the last byte or microsecond.
什么是真理?明显的,对于微优化开发者常常显示出一种过分的考虑.象通常所讲，如果软件不正确,效率也无关紧要(一个新的格言”不要关心速度除非它是正确的”, 涵盖了前一个,但也不完全一样).更通常, 效率观点一定要与其它的目标达到平衡, 像是扩充性和复用性. 极端的最佳化可能使软件特殊化,不适合变化和复用.此外，计算机硬件能力不断的增长确实允许我们对得到最后的结果有一个更轻松的态度.
All this, however, does not diminish the importance of efficiency. No one likes to wait for the responses of an interactive system, or to have to purchase more memory to run a program. So offhand attitudes to performance include much posturing; if the final system is so slow or bulky as to impede usage, those who used to declare that “speed is not that important” will not be the last to complain.
然而,所有的这些并没有减少效率的重要性.没有人喜欢等候交互系统的反应,或为执行一个程序购买更多的内存.对效率如此草率的态度包括众多心态；如果最终的系统是缓慢或庞大以至于妨碍使用, 那些过去一直宣称”速度并不重要”的人在程序还未结束时就要抱怨了.
This issue reflects what I believe to be a major characteristic of software engineering, not likely to move away soon: software construction is difficult precisely because it requires taking into account many different requirements, some of which, such as correctness, are abstract and conceptual, whereas others, such as efficiency, are concrete and bound to the properties of computer hardware.
这个议题反映了我所相信的软件工程的一个主要的特性,并不可能很快的改变: 软件构造之所以困难正因为它考虑许多不同的需求,其中,像是正确性,是抽象的和概念的,然而其它,如效率,却是具体的并依赖于计算机硬件特性。
For some scientists, software development is a branch of mathematics; for some engineers, it is a branch of applied technology. In reality, it is both. The software developer must reconcile the abstract concepts with their concrete implementations, the mathematics of correct computation with the time and space constraints deriving from physical laws and from limitations of current hardware technology. This need to please the angels as well as the beasts may be the central challenge of software engineering.
对于一些科学家来说,软件开发是数学的一个分支；对于一些工程师,它又是应用技术的一个分支.事实上,它两者皆是.软件开发者必须用他们的具体实现去调和抽象的概念,用源于自然规律和当前硬件技术限制的时间和空间约束去调和正确计算的数学概念.这种满足各方面的需求也许是软件工程中重要的挑战。
The constant improvement in computer power, impressive as it is, is not an excuse for overlooking efficiency, for at least three reasons:
实际上给人印象的是,至少有三个理由表明,计算机能力的持续改进并不是忽视效率的借口:
• Someone who purchases a bigger and faster computer wants to see some actual benefit from the extra power — to handle new problems, process previous problems faster, or process bigger versions of the previous problems in the same amount of time. Using the new computer to process the previous problems in the same amount of time will not do!
购买更大和更快计算机的人来想从这些额外能力中得到实际的好处--处理新的问题,更快的处理以前的问题, 或在相同的时间中处理早先的问题的更高版本. 使用新计算机要在相同的时间内处理早先的问题将毫无用处!
• One of the most visible effects of advances in computer power is actually to increase the lead of good algorithms over bad ones. Assume that a new machine is twice as fast as the previous one. Let n be the size of the problem to solve, and N the maximum n that can be handled by a certain algorithm in a given time. Then if the algorithm is in O (n), that is to say, runs in a time proportional to n, the new machine will enable you to handle problem sizes of about 2 * N for large N. For an algorithm in O (n2) the new machine will only yield a 41% increase of N. An algorithm in O (2n), similar to certain combinatorial, exhaustive-search algorithms, would just add one to N — not much of an improvement for your money.
实际上,提升计算机能力最显著的效果之一是比坏算法增加了好算法的领先程度.假设一个新机器比之前的机器快两倍.设n是要被解决的问题的大小,N是在给定的时间内指定算法所能处理的最大n值.接着,如果算法是O(n),也就是说,在均等的时间中运行到n,新的机器将使你能够处理大约2倍于大N的问题.对于O(n2)中的算法,新的机器只将会产生41%的N的增量.O(2n)的一个算法,类似与指定的组合穷举搜索算法,仅仅增加了一倍的N—并没有太多的改善你的经费.
• In some cases efficiency may affect correctness. A specification may state that the computer response to a certain event must occur no later than a specified time; for example, an in-flight computer must be prepared to detect and process a message from the throttle sensor fast enough to take corrective action. This connection between efficiency and correctness is not restricted to applications commonly thought of as “real time”; few people are interested in a weather forecasting model that takes twenty-four hours to predict the next day’s weather.
在一些情况下,效率可能影响正确性.规格可以规定计算机响应特定事件必需在特定时间内；举例来说，一个在飞行中的计算机必须时刻准备着侦测并能及时采取纠正措施处理来自于阀门感应器的信息. 这个效率和正确性之间的关联没有被限制到实时的普通的应用程序中去;很少有人会对花二十四个小时预知隔天天气的天气预报模型感兴趣.
Another example, although perhaps less critical, has been of frequent annoyance to me: a window management system that I used for a while was sometimes too slow to detect that the mouse cursor had moved from a window to another, so that characters typed at the keyboard, meant for a certain window, would occasionally end up in another.
另外的一个例子,虽然没有太大的影响,却时常烦恼着我:一个用了一阵子的窗囗管理系统有时太慢了,以至于不能侦测鼠标光标已经移到另外一窗囗上了.因此,为这个窗囗的键盘输入的字符,会跑到另外的窗囗里面.
In this case a performance limitation causes a violation of the specification, that is to say of correctness, which even in seemingly innocuous everyday applications can cause nasty consequences: think of what can happen if the two windows are used to send electronic mail messages to two different correspondents. For less than this marriages have been
broken, even wars started.
这种情况下,性能限制导致了规格冲突,确切地说是违反了正确性,甚至在每天看起来无关大雅的应用程序都能引起很麻烦的结果: 如果打开二个窗口给二个不同的人寄电子邮件,想想看能发生什么.小至婚姻的结束,大至战争的开始.
Because this book is focused on the concepts of object-oriented software engineering, not on implementation issues, only a few sections deal explicitly with the associated performance costs. But the concern for efficiency will be there throughout. Whenever the discussion presents an object-oriented solution to some problem, it will make sure that the solution is not just elegant but also efficient; whenever it introduces some new O-O mechanism, be it garbage collection (and other approaches to memory management for
object-oriented computation), dynamic binding, genericity or repeated inheritance, it will do so based on the knowledge that the mechanism may be implemented at a reasonable cost in time and in space; and whenever appropriate it will mention the performance consequences of the techniques studied.
因为本书把重心集中在面向对象软件工程的观念上,并不在实现上,所以只有一些内容明确地讨论相关的效率消耗.但是效率的观念将贯穿全文.只要讨论表达了一些问题的面向对象解决方案,它将会确保方案不但优雅的而且是有效的;只要介绍一些新的OO机制,譬如它的垃圾收集(和其它的面向对象计算的存储器管理方法),动态绑定,泛型或多重继承,将基于一定的知识上,这些知识的机制是在时间和空间上实现合理的消耗;任何适当的时侯,所学到的技术性能价值都会提及。
Efficiency is only one of the factors of quality; we should not (like some in the profession) let it rule our engineering lives. But it is a factor, and must be taken into consideration, whether in the construction of a software system or in the design of a programming language. If you dismiss performance, performance will dismiss you.
效率只是品质的因数之一;我们不应该让它主导我们的工程周期.但它是一个因数,无论在软件系统的构造或程式语言的设计中,一定要考虑到.如果你忽视性能,性能也将会忽视你.
Portability
移植性
Definition: portability
Portability is the ease of transferring software products to various hardware and software environments.
移植性是指易于在各种硬件和软件环境上移植软件.
Portability addresses variations not just of the physical hardware but more generally of the hardware-software machine, the one that we really program, which includes the operating system, the window system if applicable, and other fundamental tools. In the rest of this book the word “platform” will be used to denote a type of hardware-software machine; an example of platform is “Intel X86 with Windows NT” (known as “Wintel”).
移植性描述了改变,不仅仅局限于物理的硬件上,更通常是在我们编程用的硬件-软件机器上,其包括操作系统,可适用的窗囗系统,和其它的基本工具.在下面的章节中,”平台”将被用来指定硬件-软件机器的类型；一个例子是”Windows NT和Intel X86”平台(即”Wintel”).
Many of the existing platform incompatibilities are unjustified, and to a naive observer the only explanation sometimes seems to be a conspiracy to victimize humanity in general and programmers in particular. Whatever its causes, however, this diversity makes portability a major concern for both developers and users of software.
许多现存平台的不兼容性还未被证实, 而且对一位幼稚的观察者而言, 有时唯一的解释通常是牺牲人类的阴谋,特别是对程序员而言. 然而,无论是什么引起的,这个差异使移植性成为软件的开发者和使用者主要的考虑.
Ease of use
易用性Definition: ease of use
Ease of use is the ease with which people of various backgrounds and qualifications can learn to use software products and apply them to solve problems. It also covers the ease of installation, operation and monitoring.
易用性是各种不同的背景和资历的人能易于学习使用软件产品，而且应用它们解决问题.其也涵盖了安装，操作和监控的易用.
The definition insists on the various levels of expertise of potential users. This requirement poses one of the major challenges to software designers preoccupied with ease of use: how to provide detailed guidance and explanations to novice users, without bothering expert users who just want to get right down to business.
定义强调了潜在用户的各种不同水准的专长.这个需求对软件设计者造成主要的挑战之一是集中于易用性: 该如何提供详细的引导和解释给新用户,同时不烦扰仅仅对业务感兴趣的专家用户.
As with many of the other qualities discussed in this chapter, one of the keys to ease of use is structural simplicity. A well-designed system, built according to a clear, well thought-out structure, will tend to be easier to learn and use than a messy one. The condition is not sufficient, of course (what is simple and clear to the designer may be difficult and obscure to users, especially if explained in designer’s rather than user’s terms), but it helps considerably.
在本章所讨论的大部份其它的性质中,达到易用性的一个关键是结构简单化.一个设计良好,依照清晰的慎重考虑的结构构建的系统,比一个杂乱的系统更易于学习和使用.当然,这些条件并不足够,(对设计者来说的简单和清晰可能对用户很是困难的和模糊的,尤其是用设计者而不是用户的术语),但它却相当有用.
This is one of the areas where the object-oriented method is particularly productive; many O-O techniques, which appear at first to address design and implementation, also yield powerful new interface ideas that help the end users. Later chapters will introduce several examples.
这是面向对象方法有着显著生产力的领域之一. 许多OO技术,最初是为了设计和实现而出现的,也能产生强有力的新的界面概念以帮助最终用户. 稍后章节中将会介绍一些例子.
Software designers preoccupied with ease of use will also be well-advised to consider with some mistrust the precept most frequently quoted in the user interface literature, from an early article by Hansen: know the user. The argument is that a good designer must make an effort to understand the system’s intended user community. This view ignores one of the features of successful systems: they always outgrow their initial audience. (Two old and famous examples are Fortran, conceived as a tool to solve the problem of the small community of engineers and scientists programming the IBM 704, and Unix, meant for internal use at Bell Laboratories.) A system designed for a specific group will rely on assumptions that simply do not hold for a larger audience.
关注易用性的软件设计者也生思熟虑的考虑了一些令人疑惑的规则, 这些规则很频繁被用户界面文献所引述.规则源于Hansen的一篇早期文章: 了解用户(know the user). 其讨论是一个好的设计者一定要尽力去了解系统和用户群体. 这个观点忽视了成功系统的一个特点: 他们总是大于他们的初始用户. (二个以前的出名例子是:Fortran被构思为一个工具是为了解决工程师和科学家这种小团体在IBM704上的问题; Unix只在贝尔实验室小范围的内部使用.) 一个为特定的群体设计的系统会依赖于这样的一种假设,即广大的群体并不能简单的掌握.
Good user interface designers follow a more prudent policy. They make as limited assumptions about their users as they can. When you design an interactive system, you may expect that users are members of the human race and that they can read, move a mouse, click a button, and type (slowly); not much more. If the software addresses a specialized application area, you may perhaps assume that your users are familiar with its basic concepts. But even that is risky. To reverse-paraphrase Hansen’s advice:
一个好的用户界面设计者会依照一个更审慎的策略. 他们尽可能的对他们的用户作有限的假设.当你设计一个交互系统时,你可能认为用户是一个正常的人,他们会阅读,会移动鼠标, 会点击按钮,而且会打字(很慢); 差不多就这些了.如果软件用于一个特殊的应用领域,你也许会认为你的用户熟悉基本的概念. 但恰恰相反,这是危险的. 相反于Hansen的忠告是:
User Interface Design principle
Do not pretend you know the user; you don’t.
用户界面设计原则
不要假装你了解用户, 其实你并不.
Functionality
功能性Definition: functionality
Functionality is the extent of possibilities provided by a system.
功能性是系统提供的可能性范围.
One of the most difficult problems facing a project leader is to know how much functionality is enough. The pressure for more facilities, known in industry parlance as featurism (often “creeping featurism”), is constantly there. Its consequences are bad for internal projects, where the pressure comes from users within the same company, and worse for commercial products, as the most prominent part of a journalist’s comparative review is often the table listing side by side the features offered by competing products.
对一位项目主管来说的最困难的问题之一是要知道多少功能才够.更多的功能压力,在工业术语中是featurism(时常”creeping featurism”),总是永恒不变地. 其结果对内部的项目不利,这里的压力来自同一个公司里的用户,同时,对商业产品来说更糟糕,因为新闻记者的对比测评中最显著的部份时常是把竞争产品所提供的特性排列出来.
Featurism is actually the combination of two problems, one more difficult than the other. The easier problem is the loss of consistency that may result from the addition of new features, affecting its ease of use. Users are indeed known to complain that all the “bells and whistles” of a product’s new version make it horrendously complex. Such comments should be taken with a grain of salt, however, since the new features do not come out of nowhere: most of the time they have been requested by users — other users. What to me looks like a superfluous trinket may be an indispensable facility to you.
Featurism实际上是二个问题的组合, 一个比一个困难. 较容易的问题是稳定性的损失可能起因于新特性的增加,并影响着易用性.用户了解后就会抱怨产品的新版本中所有的操作变得复杂.这样的解释不可尽信,然而,由于新的特性并不是到处都有: 大部份都是用户-其它的用户所要求的.在我来看一个多余的小饰品,可能是对你而言是一个不可或缺之物.
The solution here is to work again and again on the consistency of the overall product, trying to make everything fit into a general mold. A good software product is based on a small number of powerful ideas; even if it has many specialized features, they should all be explainable as consequences of these basic concepts. The “grand plan” must be visible, and everything should have its place in it.
在这里,解决的方法是要在整体产品的一致性上反复工作,试着使所有的一切都适合一种通用模式.一种好的软件产品应基于少量的有效概念；即使它有许多特殊特性,他们全部都应该由这些基本的概念来解释. 壮观的计划一定是可见的，所有事物应该在里面都有它自己的位置.
The more difficult problem is to avoid being so focused on features as to forget the other qualities. Projects commonly make such a mistake, a situation vividly pictured by Roger Osmond in the form of two possible paths to a project’s completion:
更困难一些的问题是要避免集中在特性上而忽视其它的品质.项目通常会犯这样的错误，这种情形被Roger Osmond生动地描绘成通向项目完成的二个可能的路径形式:
The bottom curve (black) is all too common: in the hectic race to add more features, the development loses track of the overall quality. The final phase, intended to get things right at last, can be long and stressful. If, under users’ or competitors’ pressure, you are forced to release the product early — at stages marked by black squares in the figure — the outcome may be damaging to your reputation.
底部曲线(黑色的)实在是太普通了: 在狂热的竞争中加入更多的特性,却忽视了整体质量.最终考虑正确性的时侯,最后阶段只能延长而紧迫.在使用者或竞争者的压力下，如果你被迫要提早发行产品—在图上的黑色正方形记号的阶段—其结果是损坏了你的名誉.
What Osmond suggests (the color curve) is, aided by the quality-enhancing techniques of O-O development, to maintain the quality level constant throughout the project for all aspects but functionality. You just do not compromise on reliability, extendibility and the like: you refuse to proceed with new features until you are happy with the features you have.
Osmond的建议(彩色的曲线)是,借助于提高品质的OO开发技术,除了功能性之外的其它方面,在项目各处都维持着不变的品质水准. 你不应该在可靠性,扩充性和类似问题上妥协: 你应拒绝继续开发新的特性,直到你对所有的特性都感到满意.
This method is tougher to enforce on a day-to-day basis because of the pressures mentioned, but yields a more effective software process and often a better product in the end. Even if the final result is the same, as assumed in the figure, it should be reached sooner (although the figure does not show time). Following the suggested path also means that the decision to release an early version — at one of the points marked by colored squares in the figure — becomes, if not easier, at least simpler: it will be based on your assessment of whether what you have so far covers a large enough share of the full feature set to attract prospective customers rather than drive them away. The question “is it good enough?” (as in “will it not crash?”) should not be a factor.
由于有这些压力,这个坚持在日复一日的基础上的方法是痛苦的,但能产生一个更高效的软件过程并最终得到一个更好的产品.即使最终的结果是一样的,如图所假定，它也应该能较快的实现(尽管此图没有显示时间).沿着建议的路径也意谓要发布早期版本的决定--在图中彩色正方形记号的任一点上—会变得,如果不那么容易,至少比较简单: 它将会以你的评估为基础:是否你迄今为止已经包括够大的完整的特性可以吸引期待中的客户,而不是让他们失望.”它足够好吗?”这样的问题不应该成为一个因数(如”它将不会崩溃?").
As any reader who has led a software project will know, it is easier to approve such advice than to apply it. But every project should strive to follow the approach represented by the better one of the two Osmond curves. It goes well with the cluster model introduced in a later chapter as the general scheme for disciplined object-oriented development.
曾领导过软件项目的任何读者都会知道,赞同这样的忠告比应用起来容易的多.但是每个项目应该努力地跟随二个Osmond曲线中比较好的那个表现方式. 作为有效的面向对象开发的通用方案,它和在后面的章节中被介绍的群集模型一起运做得较好.
Timeliness
Definition: timeliness
Timeliness is the ability of a software system to be released when or before its users want it.
时效性是指软件系统在用户需要时或之前发布的能力.
时效性
时效性
Timeliness is one of the great frustrations of our industry. A great software product that appears too late might miss its target altogether. This is true in other industries too, but few evolve as quickly as software.
时效性是我们产业中重大的挫折之一. 一个重大的软件产品出现的太迟可能完全错过了它的目标.在其它的产业中也是一样,但很少象软件那样.
Timeliness is still, for large projects, an uncommon phenomenon. When Microsoft announced that the latest release of its principal operating system, several years in the making, would be delivered one month early, the event was newsworthy enough to make (at the top of an article recalling the lengthy delays that affected earlier projects) the frontpage headline of ComputerWorld.
对大项目来说,时效性一直是一个罕见的现象.当微软宣布,历经几年开发的其主打的操作系统最终版本将提前一个月发布,这个新闻完全有价值出现在<<计算机世界>>的头版.
Other qualities
其它的品质
Other qualities beside the ones discussed so far affect users of software systems and the people who purchase these systems or commission their development. In particular:
和迄今为止所讨论的一样,其它的品质也影响着软件系统的用户,系统订购商或开发委托商. 特别是:
• Verifiability is the ease of preparing acceptance procedures, especially test data, and procedures for detecting failures and tracing them to errors during the validation and operation phases.
校验性是指易于准备验收程序, 特别是测试数据,和在确认和操作阶段检测失败并跟踪错误的程序.
• Integrity is the ability of software systems to protect their various components (programs, data) against unauthorized access and modification.
完整性是指软件系统保护各种组件(程序,数据)防止未经授权的访问和修改的能力.
• Repairability is the ability to facilitate the repair of defects.
修复性是指易于修复损坏的能力.
• Economy, the companion of timeliness, is the ability of a system to be completed on or below its assigned budget.
经济性,与时效性同义, 指系统能完全符合或低于分配的预算.
About documentation
关于文档
In a list of software quality factors, one might expect to find the presence of good documentation as one of the requirements. But this is not a separate quality factor; instead, the need for documentation is a consequence of the other quality factors seen above. We may distinguish between three kinds of documentation:
在一连串的软件品质因数中,一个可以想到的是找出编写良好文档的方法作为需求之一. 但这不是一个独立的品质因数；相反,对文档的需要是上述其它品质因数的结果.我们可以区别三种类型的文档:
• The need for external documentation, which enables users to understand the power of a system and use it conveniently, is a consequence of the definition of ease of use.
外部文档的需要,使用户能够理解系统的能力和方便地使用它,是易用性定义的结果.
• The need for internal documentation, which enables software developers to understand the structure and implementation of a system, is a consequence of the extendibility requirement.
内部文档的需要,使软件开发者能够理解架构和系统实现,是扩充性需求的结果.
• The need for module interface documentation, enabling software developers to understand the functions provided by a module without having to understand its implementation, is a consequence of the reusability requirement. It also follows from extendibility, as module interface documentation makes it possible to determine whether a certain change need affect a certain module.
模块接口文档的需要是复用性需求的结果,使得软件开发者能理解由一个模块提供的功能而不必知道它的实现.它也从扩充性中得出,作为模块接口文档, 能够决定是否某个特定的改变需要影响特定的模块.
Rather than treating documentation as a product separate from the software proper, it is preferable to make the software as self-documenting as possible. This applies to all three kinds of documentation:
更可取的是使软件尽可能的自己生成文档, 这比把文档完全地和软件分离开来要好. 这适用于所有的三种类型的文档:
• By including on-line “help” facilities and adhering to clear and consistent user interface conventions, you alleviate the task of the authors of user manuals and other forms of external documentation.
通过包括在线”帮助”工具并且使用清晰一致的用户界面风格,你能减轻用户指南和其它形式的外部文档的作者的任务.
• A good implementation language will remove much of the need for internal documentation if it favors clarity and structure. This will be one of the major requirements on the object-oriented notation developed throughout this book.
如果思路清楚和结构化,一个良好的实现语言将不再需要很多的内在文档.在全书中的面向对象符号的开发上,这将会是一个主要的必要条件.
• The notation will support information hiding and other techniques (such as assertions) for separating the interface of modules from their implementation. It is then possible to use tools to produce module interface documentation automatically from module texts. This too is one of the topics studied in detail in later chapters.
为了从模块的实现中分离出接口,符号将会支持信息隐藏和其它技术(如断言).然后,使用工具从模块文本中自动地产生模块接口文档. 这也是主题之一,在后面的章节中会详细地学习到.
All these techniques lessen the role of traditional documentation, although of course we cannot expect them to remove it completely.
所有的这些技术会减少传统的文档编写任务,当然,我们不能够期待它们能完全地被替代.
Tradeoffs
折衷
In this review of external software quality factors, we have encountered requirements that may conflict with one another.
在外部的软件品质因数的讨论中,我们已经遇到了彼此需求的冲突.
How can one get integrity without introducing protections of various kinds, which will inevitably hamper ease of use? Economy often seems to fight with functionality. Optimal efficiency would require perfect adaptation to a particular hardware and software environment, which is the opposite of portability, and perfect adaptation to a specification, where reusability pushes towards solving problems more general than the one initially given. Timeliness pressures might tempt us to use “Rapid Application Development” techniques whose results may not enjoy much extendibility.
如何能不用引入各种不同类型的保护而得到完整性, 这将会不可避免的妨碍易用性? 经济性时常对抗功能性. 最佳的高效性需要对特别的硬件和软件环境正确的处理,这又和移植性对立; 修改一个规格, 复用性又有问题了,这又超出了当初赋予它解决一般问题的使命.时效性的压力可能诱惑我们使用”快速应用开发”的技术,这不可能兼顾扩充性.
Although it is in many cases possible to find a solution that reconciles apparently conflicting factors, you will sometimes need to make tradeoffs. Too often, developers make these tradeoffs implicitly, without taking the time to examine the issues involved and the various choices available; efficiency tends to be the dominating factor in such silent decisions. A true software engineering approach implies an effort to state the criteria clearly and make the choices consciously.
虽然在许多情况下能够找到解决方案去解决明显的冲突因数,但你有时需要采取折衷方案.通常,开发者会暗中地采取这些折衷,并没有花时间去调查有关的方案和各种不同的有效选择; 效率往往是支配这种沈默的决定因数. 一个真正的软件工程方法意味着一种成果,即清晰地陈述标准并有意识地作出选择.
Necessary as tradeoffs between quality factors may be, one factor stands out from the rest: correctness. There is never any justification for compromising correctness for the sake of other concerns such as efficiency. If the software does not perform its function, the rest is useless.
在品质因数之间的必需要折衷的话,一个突出的要考虑的因数是:正确性. 从没有一个正当的理由,为了其它的关系如高效性,去折衷正确性.如果软件不能运行它的功能,其余的都没用.
Key concerns
关键
All the qualities discussed above are important. But in the current state of the software industry, four stand out:
所有的在上面讨论的品质都很重要. 但是在软件工业目前的状态下,有四个最为突出:
• Correctness and robustness: it is still too difficult to produce software without defects (bugs), and too hard to correct the defects once they are there. Techniques for improving correctness and robustness are of the same general flavors: more systematic approaches to software construction; more formal specifications; built-in checks throughout the software construction process (not just after-the-fact testing and debugging); better language mechanisms such as static typing, assertions, automatic memory management and disciplined exception handling, enabling developers to state correctness and robustness requirements, and enabling tools to detect inconsistencies before they lead to defects. Because of this closeness of correctness and robustness issues, it is convenient to use a more general term, reliability, to cover both factors.
正确性和健壮性: 对产生没有缺陷(bugs)的软件来说,它总是太困难了,对于改正存在的缺陷也很艰难.提高正确性和健壮性的技术基本上是相同的: 更系统化的软件构造;更正式的规格; 贯穿与软件构造过程的内建检查机制 (不仅仅是事后测试和除错);更好的语言机制,像是静态类型,断言,自动内存管理和科学的异常处理,这些都能使开发者陈述正确性和健壮性需求, 能使工具在导致错误之前发现不一致. 因为正确性和健壮性议题很接近,所以很方便的使用一个较一般的术语,可靠性,来涵盖这两个因数.
• Extendibility and reusability: software should be easier to change; the software elements we produce should be more generally applicable, and there should exist a larger inventory of general-purpose components that we can reuse when developing a new system. Here again, similar ideas are useful for improving both qualities: any idea that helps produce more decentralized architectures, in which the components are self-contained and only communicate through restricted and clearly defined channels, will help. The term modularity will cover reusability and extendibility.
扩充性和复用性: 软件应该更容易改变; 我们产生出来的软件元素应该是更普遍适用的,而且当开发一个新系统的时候, 手边应该有很多的有关组件的详细目录,这些通用的组件我们能重复使用.这里再一次重申，对改良这两个品质来说,类似的方法都有效: 有助于产品分散架构的任何方法都会有用,在分散架构中,组件是独立的而且只能通过限定和清晰定义的接口通讯.术语模块性将会涵盖扩充性和复用性.
As studied in detail in subsequent chapters, the object-oriented method can significantly improve these four quality factors — which is why it is so attractive. It also has significant contributions to make on other aspects, in particular:
在后续的章节中会详细地了解到，面向对象的方法能显著地改良这四个品质因数—这就是它为什么会如此吸引人的原因.特别的,它也有重要的贡献于其它的方面:
• Compatibility: the method promotes a common design style and standardized module and system interfaces, which help produce systems that will work together.
兼容性: 面向对象方法会促进一种通用的设计风格和标准化的模块和系统界面,这会帮助产品系统共同工作。
• Portability: with its emphasis on abstraction and information hiding, object technology encourages designers to distinguish between specification and implementation properties, facilitating porting efforts. The techniques of polymorphism and dynamic binding will even make it possible to write systems that automatically adapt to various components of the hardware-software machine, for example different window systems or different database management systems.
移植性: 藉由强调抽象化和信息隐藏，对象技术鼓励设计者区别规格特性和实现特性,并使连接效果更容易. 要编写系统以自动地适应硬件-软件机器上各种不同的组件,多态技术和动态绑定将会使之可能,举例来说不同的窗囗系统或不同的数据库管理系统.
• Ease of use: the contribution of O-O tools to modern interactive systems and especially their user interfaces is well known, to the point that it sometimes obscures other aspects (ad copy writers are not the only people who call “object-oriented” any system that uses icons, windows and mouse-driven input).
易用性: 对于现代的交互系统尤其它们的用户界面,OO工具广为人知的贡献是指明了其它的模糊的方面(对使用图像,视窗和鼠标驱动的输入任何的”面向对象”系统来说,广告拷贝的作者并不是唯一使用的人).
• Efficiency: as noted above, although the extra power or object-oriented techniques at first appears to carry a price, relying on professional-quality reusable components can often yield considerable performance improvements.
高效性: 如上所说，虽然起先额外的能力或面向对象技术似乎带来了费用问题,但依赖专业品质的可复用组件时常能带来可观的性能提升.
• Timeliness, economy and functionality: O-O techniques enable those who master them to produce software faster and at less cost; they facilitate addition of functions, and may even of themselves suggest new functions to add.
时效性,经济性和功能性: OO技术使那些掌握它们的人能编写出更快的软件和花费更少的费用;他们可以方便的增加功能,更甚至他们自己建议增加新的功能.
In spite of all these advances, we should keep in mind that the object-oriented method is not a panacea, and that many of the habitual issues of software engineering remain. Helping to address a problem is not the same as solving the problem.
尽管有这些优点，我们应该记住面向对象的方法并不是一个万能药, 而且软件工程中许多传统的议题仍旧存在.有助于讨论一个问题并不等同与解决这个问题.
1.3 ABOUT SOFTWARE MAINTENANCE
1.3 关于软件维护
The list of factors did not include a frequently quoted quality: maintainability. To understand why, we must take a closer look at the underlying notion, maintenance.
因数的列表没有包括一个时常被引述的品质:维护性.要知道为什么,我们需要进一步了解下面的观念,维护.
Maintenance is what happens after a software product has been delivered. Discussions of software methodology tend to focus on the development phase; so do introductory programming courses. But it is widely estimated that 70% of the cost of software is devoted to maintenance. No study of software quality can be satisfactory if it neglects this aspect.
维护发生在一个软件产品发布之后. 软件方法学的讨论容易把重心集中在开发阶段;所以介绍的是程序规划课程. 但是普遍地估计软件的70%的费用集中于维护.如果疏忽这个方面, 软件品质的研究是不会令人满意的.
What does “maintenance” mean for software? A minute’s reflection shows this term to be a misnomer: a software product does not wear out from repeated usage, and thus need not be “maintained” the way a car or a TV set does. In fact, the word is used by software people to describe some noble and some not so noble activities. The noble part is modification: as the specifications of computer systems change, reflecting changes in the external world, so must the systems themselves. The less noble part is late debugging:
removing errors that should never have been there in the first place.
“维护”对软件意谓着什么? 瞬间地反映是这个术语用词不当: 一种软件产品在重复的使用中是不会磨损的,因此并不需要象汽车或电视机那样的”维护”. 事实上,这个词被软件人员用以描述一些重要的和一些并不重要的活动.重要的部份是指修改:当计算机系统的规格改变了,其反映了外部的世界的改变, 因此系统自己也必须要改变.并不重要的部份是指后期除错: 首先移除那些不应该在那里的错误。
The above chart, drawn from a milestone study by Lientz and Swanson, sheds some light on what the catch-all term of maintenance really covers. The study surveyed 487 installations developing software of all kinds; although it is a bit old, more recent publications confirm the same general results. It shows the percentage of maintenance costs going into each of a number of maintenance activities identified by the authors.
上述的图表, 是Lientz和Swanson在一项里程碑研究中所绘,清楚明白地显示了所有真正的维护活动.研究调查了487个开发中的所有类型的软件；虽然它有一点陈旧，但是最近的研究确认了相同的结果.它显示了作者所描绘的每一个维护活动所占维护费用的百分比.
More than two-fifths of the cost is devoted to user-requested extensions and modifications. This is what was called above the noble part of maintenance, which is also the inevitable part. The unanswered question is how much of the overall effort the industry could spare if it built its software from the start with more concern for extendibility. We may legitimately expect object technology to help.
五分之二多的费用投入于用户需求的扩充和修改.这就是所谓的重要部份的维护,也是不可避免的部份.如果从开始构造软件就更多的关注扩充性,那么一个得不到答案的问题是投入全部努力的产业会节省下来多少.我们可以合理地期待对象技术的帮助.
The second item in decreasing order of percentage cost is particularly interesting: effect of changes in data formats. When the physical structure of files and other data items change, programs must be adapted. For example, when the US Postal Service, a few years ago, introduced the “5+4” postal code for large companies (using nine digits instead of five), numerous programs that dealt with addresses and “knew” that a postal code was exactly five digits long had to be rewritten, an effort which press accounts estimated in the hundreds of millions of dollars.
排在费用比率的第二项特别地有趣: 在数据格式方面的改变效果. 当文件和其它数据项的物理结构变化后,程序一定也要跟着变化.举例来说,数年以前,当美国邮政服务公司(UPS)为大的公司使用了”5+4”邮政编码时(使用九位数取代五位数),大量的程序不得不重写,这些程序一直使用五位数的邮政编码.这一结果花费了数百万的美元.
Many readers will have received the beautiful brochures for a set of conferences — not a single event, but a sequence of sessions in many cities — devoted to the “millennium problem”: how to go about upgrading the myriads of date-sensitive programs whose authors never for a moment thought that a date could exist beyond the twentieth century. The zip code adaptation effort pales in comparison. Jorge Luis Borges would have liked the idea: since presumably few people care about what will happen on 1 January 3000, this must be the tiniest topic to which a conference series, or for that matter a conference, has been or will ever be devoted in the history of humanity: a single decimal digit.
许多读者会因为一组”千年虫”问题收到漂亮的会议请柬—这不是一次单独的活动,是在许多城市一系列的会议: 该如何升级数万个日期敏感的程序,这些程序作者从未想过日期可以超过二十世纪.相比之下, 邮政编码的修改又算什么.Jorge Luis Borges喜欢这样的一个想法:既然推测起来极少有人会关心3000年一月一日将会发生的事,那么这一定是一个会
议系列或相关会议中的最极小的主题, 或者已经成为人类的历史了: 一个单一的十进制数字.
The issue is not that some part of the program knows the physical structure of data: this is inevitable since the data must eventually be accessed for internal handling. But with traditional design techniques this knowledge is spread out over too many parts of the system, causing unjustifiably large program changes if some of the physical structure changes — as it inevitably will. In other words, if postal codes go from five to nine digits, or dates require one more digit, it is reasonable to expect that a program manipulating the codes or the dates will need to be adapted; what is not acceptable is to have the knowledge of the exact length of the data plastered all across the program, so that changing that length will cause program changes of a magnitude out of proportion with the conceptual size of the specification change.
结果并不是那些知道数据的物理结构的程序的一部份: 既然数据最终必须被内部处理所存取,这就是不可避免了. 但是由于传统的设计技术,这种观点遍及了系统的太多部份, 如果一些物理结构被改变,就会引起意想不到的大量程序变化--这不可避免.换句话说，如果邮政编码从五位数转成到九位数,或日期需要增加一位数, 期望修改操作邮编或日期的程序是很合理的; 不可接受的是修改数据的精确长度遍及整个程序, 因此,变更长度将会引起程序的巨大变化,这可不是变化规格大小可比拟的.
The theory of abstract data types will provide the key to this problem, by allowing programs to access data by external properties rather than physical implementation.
抽象数据类型的理论将会提供这个问题的答案, 既允许程序用外部特性而非物理实现来存取数据.
Another significant item in the distribution of activities is the low percentage (5.5%) of documentation costs. Remember that these are costs of tasks done at maintenance time.
The observation here — at least the speculation, in the absence of more specific data — is that a project will either take care of its documentation as part of development or not do it at all. We will learn to use a design style in which much of the documentation is actually embedded in the software, with special tools available to extract it.
在分配图上,另一个重要的条目是文档费用的低百分比(5.5%).请记住这些是在维护期间所完成的任务费用. 在这里,能观测到--至少在缺乏更详细数据的情况下能推测到--一个项目或把文档当作开发的一部份，或根本不去管它. 我们将会学习使用一种设计风格,大量的文档实际上是嵌入在软件中的,用特别的工具去提取它们.
The next items in Lientz and Swanson’s list are also interesting, if less directly relevant to the topics of this book. Emergency bug fixes (done in haste when a user reports that the program is not producing the expected results or behaves in some catastrophic way) cost more than routine, scheduled corrections. This is not only because they must be performed under heavy pressure, but also because they disrupt the orderly process of delivering new releases, and may introduce new errors. The last two activities account for small percentages:
如果不关心本书的主题,在Lientz和Swanson's的列表中的下一条也很有趣. 紧急错误(当一个用户报告程序不能产生预期的结果或发生灾难性的行为时紧急处理)修改的花费超过正常情况下计划好的校正. 这不但是因为他们在巨大的压力之下一定要完成,而且因为他们打乱了发布新版本的秩序,并可能带来新的错误.最后二个条款占了小百分比:
• One is efficiency improvements; this seems to suggest that once a system works, project managers and programmers are often reluctant to disrupt it in the hope of performance improvements, and prefer to leave good enough alone. (When considering the “first make it right, then make it fast” precept, many projects are probably happy enough to stop at the first of these steps.)
一是有效性的提高；一个系统一经工作, 项目经理和程序员都不情愿为了提高有效性而打断它, 宁愿置之不理. (当考虑”首先使它正确,然后使它快”的教训时，许多项目或许会很高兴的在开始就停下来).
• Also accounting for a small percentage is “transfer to new environments”. A possible interpretation (again a conjecture in the absence of more detailed data) is that there are two kinds of program with respect to portability, with little in-between: some programs are designed with portability in mind, and cost relatively little to port; others are so closely tied to their original platform, and would be so difficult to port, that developers do not even try.
"迁移至新环境"也占很小的比例.一个可能的解释(也是一个缺乏比较详细数据的推测)是这里有关于二种类型程序的可移植性,其间的差别很小:一些程序设计时考虑了移植性,而且移植相对花费较少；其它的绑定到他们的最初平台上,移植非常困难,开发者根本无法尝试.
1.4 KEY CONCEPTS INTRODUCED IN THIS CHAPTER
1.4 摘要
• The purpose of software engineering is to find ways of building quality software.
软件工程的目的是要寻找构建软件品质的方法.
• Rather than a single factor, quality in software is best viewed as a tradeoff between a set of different goals.
并非基于一个单个的因数, 软件品质是在一组不同的目标之间作出最好的折衷选择.
• External factors, perceptible to users and clients, should be distinguished from internal factors, perceptible to designers and implementors.
用户和客户能察觉到的外部因数,应该和设计者与实现者所能察觉的内在因数有所区别.
• What matters is the external factors, but they can only be achieved through the internal factors.
重要的是外部因数，但是它们只能通过内在因数来完成.
• A list of basic external quality factors was presented. Those for which current software is most badly in need of better methods, and which the object-oriented method directly addresses, are the safety-related factors correctness and robustness, together known as reliability, and the factors requiring more decentralized software architectures: reusability and extendibility, together known as modularity.
介绍了一系列基本的外部质量因数. 目前的软件急需更好的方法和面向对象的方法来描述的,是安全相关的因数:正确性和健壯性,综合起来是可靠性,同时更多的因数需要分散的软件结构:复用性和扩充性,一起即为模块性.
• Software maintenance, which consumes a large portion of software costs, is penalized by the difficulty of implementing changes in software products, and by the over-dependence of programs on the physical structure of the data they manipulate.
消耗大部分费用的软件维护,受制与在软件产品中实现变化的困难性,受制与过于依赖所操作的物理数据结构.
