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
在達到正確性的條件中,我們只關心每個層次的正確性保證,這是假設在較低的層次正確的基礎上的. 這只是現實的技術,它完成關係分離,並且讓我們把有限的問題集中在一個層次上. 你不能有效地檢查在高級語言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. “
當我們學習異常處理的時候,反常情況的定義將會再次用到.它意味着正常和反常情況的觀念總是相對於特定的規格;一個反常情況僅僅只是一個不是被規格所涵蓋的事件.如果你放寬規格,反常情況就變成了正常的--即使他們符合某種事件,像是一個你不希望發生的錯誤的用戶輸入.這種情況下,”正常”並不意謂”適當”,只是僅僅”在軟件的設計中規劃好的”. 雖然起先錯誤的輸入認爲是正常的情況,這看上去是荒謬的,但是任何其它的方法會不得不依賴主觀的標準,同樣都是無用的.
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.
消耗大部分費用的軟件維護,受制與在軟件產品中實現變化的困難性,受制與過於依賴所操作的物理數據結構.