外文翻譯--《軟件工程-實踐者的研究方法》

1、<p><b>　　附　　錄</b></p><p>　　Software Engineering-A PRACTITIONER’S APPROACH</p><p>　　Written by Roger S. Pressman, Ph.D. （P.340-P.343）</p><p>　　13.3　DESIGN PRINCIPLES

2、</p><p>　　Software design is both a process and a model. The design process is a sequence of steps that enable the designer to describe all aspects of the software to be built. It is　important to note, howev

3、er, that the design process is not simply a cookbook. Creative</p><p>　　skill, past experience, a sense of what makes “good” software, and an overall commitment to quality are critical success factors for a

4、competent design.</p><p>　　The design model is the equivalent of an architect’s plans for a house. It begins by</p><p>　　representing the totality of the thing to be built (e.g., a three-dimensi

5、onal rendering of the house) and slowly refines the thing to provide guidance for constructing each detail (e.g., the plumbing layout). Similarly, the design model that is created for software provides a variety of diffe

6、rent views of the computer software.</p><p>　　Basic design principles enable the software engineer to navigate the design process.Davis suggests a set of principles for software design, which have been adapt

7、ed and extended in the following list:</p><p>　　? The design process should not suffer from “tunnel vision.” A good designer should consider alternative approaches, judging each based on the requirements of

8、the problem, the resources available to do the job, and the design concepts presented in Section 13.4.</p><p>　　? The design should be traceable to the analysis model. Because a single element of the design

9、model often traces to multiple requirements, it is necessary to have a means for tracking how requirements have been satisfied by the design model.</p><p>　　? The design should not reinvent the wheel. System

10、s are constructed using a set of design patterns, many of which have likely been encountered before.These patterns should always be chosen as an alternative to reinvention.Time is short and resources are limited! Design

11、time should be invested in representing truly new ideas and integrating those patterns that already exist.</p><p>　　? The design should “minimize the intellectual distance” </p><p>　　between the

12、 software and the problem as it exists in the real world. That is, the structure of the software design should (whenever possible)mimic the structure of the problem domain.</p><p>　　? The design should exhib

13、it uniformity and integration. A design is uniform if it appears that one person developed the entire thing. Rules of style and format should be defined for a design team before design work begins. A design is integrated

14、 if care is taken in defining interfaces between design Components.</p><p>　　? The design should be structured to accommodate change. The design concepts discussed in the next section enable a design to achi

15、eve this principle.</p><p>　　? The design should be structured to degrade gently, even when aberrant data, events, or operating conditions are encountered. Well designed software should never “bomb.” It shou

16、ld be designed to accommodate unusual circumstances, and if it must terminate processing, do so in a graceful manner.</p><p>　　? Design is not coding, coding is not design. Even when detailed procedural desi

17、gns are created for program components, the level of abstraction of the design model is higher than source code. The only design decisions made at the coding level address the small implementation details that enable the

18、 procedural design to be coded.</p><p>　　? The design should be assessed for quality as it is being created, not after the fact. A variety of design concepts (Section 13.4) and design measures(Chapters 19 an

19、d 24) are available to assist the designer in assessing quality.</p><p>　　? The design should be reviewed to minimize conceptual (semantic)errors. There is sometimes a tendency to focus on minutiae when the

20、design is reviewed, missing the forest for the trees. A design team should ensure that major conceptual elements of the design (omissions, ambiguity, inconsistency) have been addressed before worrying about the syntax of

21、 the design model.</p><p>　　When these design principles are properly applied, the software engineer creates a design that exhibits both external and internal quality factors . External quality factors are t

22、hose properties of the software that can be readily observed by users (e.g., speed,reliability, correctness, usability).Internal quality factors are of importance to software engineers. They lead to a high-quality design

23、 from the technical perspective. To achieve internal quality factors, the designer must understand ba</p><p>　　13.4 　DESIGN CONCEPTS</p><p>　　A set of fundamental software design concepts has ev

24、olved over the past four decades.Although the degree of interest in each concept has varied over the years, each has stood the test of time. Each provides the software designer with a foundation from which more sophistic

25、ated design methods can be applied. Each helps the software engineer to answer the following questions:</p><p>　　? What criteria can be used to partition software into individual components?</p><p

26、>　　? How is function or data structure detail separated from a conceptual representation</p><p>　　of the software?</p><p>　　? What uniform criteria define the technical quality of a software

27、design?</p><p>　　M. A. Jackson once said: "The beginning of wisdom for a [software engineer] is to recognize the difference between getting a program to work, and getting it right". Fundamental sof

28、tware design concepts provide the necessary framework for "getting it right."</p><p>　　13.4.1 　Abstraction</p><p>　　When we consider a modular solution to any problem, many levels of a

29、bstraction can be posed. At the highest level of abstraction, a solution is stated in broad terms using the language of the problem environment. At lower levels of abstraction, a more procedural orientation is taken. Pro

30、blem-oriented terminology is coupled with implementation-oriented terminology in an effort to state a solution. Finally, at the lowest level of abstraction, the solution is stated in a manner that can be directly</p&g

31、t;<p>　　The psychological notion of "abstraction" permits one to concentrate on a problem at some level of generalization without regard to irrelevant low level details; use of abstraction also permits o

32、ne to work with concepts and terms that are familiar in the problem environment without having to transform them to an unfamiliar structure . . .</p><p>　　Each step in the software process is a refinement in

33、 the level of abstraction of the</p><p>　　software solution. During system engineering, software is allocated as an element of a computer-based system. During software requirements analysis, the software sol

34、ution is stated in terms "that are familiar in the problem environment." As we move through the design process, the level of abstraction is reduced. Finally, the lowest level of abstraction is reached when sour

35、ce code is generated.</p><p>　　As we move through different levels of abstraction, we work to create procedural and data abstractions. A procedural abstraction is a named sequence of instructions that has a

36、specific and limited function. An example of a procedural abstraction would</p><p>　　be the word open for a door. Open implies a long sequence of procedural steps (e.g.,walk to the door, reach out and grasp

37、knob, turn knob and pull door, step away from moving door, etc.).</p><p>　　A data abstraction is a named collection of data that describes a data object Chapter12). In the context of the procedural abstrac

38、tion open, we can define a data abstraction called door. Like any data object, the data abstraction for door would encompass a set of attributes that describe the door (e.g., door type, swing direction, pening mechanism,

39、 weight, dimensions). It follows that the procedural abstraction open would make use of information contained in the attributes of the data abstract</p><p>　　Many modern programming languages provide mechani

40、sms for creating abstract data types. For example, the Ada package is a programming language mechanism that provides support for both data and procedural abstraction. The original abstract data type is used as a template

41、 or generic data structure from which other data structures can be instantiated.</p><p>　　Control abstraction is the third form of abstraction used in software design. Like procedural and data abstraction, c

42、ontrol abstraction implies a program control mechanism without specifying internal details. An example of a control abstraction is the synchronization semaphore used to coordinate activities in an operating system.The co

43、ncept of the control abstraction is discussed briefly in Chapter 14.</p><p>　　13.4.2 　Refinement</p><p>　　Stepwise refinement is a top-down design strategy originally proposed by Niklaus Wirth.

44、A program is developed by successively refining levels of procedural detail.A hierarchy is developed by decomposing a macroscopic statement of function (a procedural abstraction) in a stepwise fashion until programming l

45、anguage statements are reached. An overview of the concept is provided by Wirth:</p><p>　　In each step (of the refinement), one or several instructions of the given program are decomposed into more detailed

46、instructions. This successive decomposition or refinement of specifications terminates when all instructions are expressed in terms of any underlying computer or programming language . . . As tasks are refined, so the da

47、ta may have to be refined, decomposed, or structured, and it is natural to refine the program and the data specifications in parallel.</p><p>　　Every refinement step implies some design decisions. It is impo

48、rtant that . . . the programmer be aware of the underlying criteria (for design decisions) and of the existence of alternative solutions . . .</p><p>　　The process of program refinement proposed by Wirth is

49、analogous to the process of　refinement and partitioning that is used during requirements analysis. The difference is in the level of implementation detail that is considered, not the approach.</p><p>　　Refin

50、ement is actually a process of elaboration.We begin with a statement of function(or description of information) that is defined at a high level of abstraction. That is, the statement describes function or information con

51、ceptually but provides no information about the internal workings of the function or the internal structure of the information. Refinement causes the designer to elaborate on the original statement, providing more and mo

52、re detail as each successive refinement (elaboration) o</p><p>　　Abstraction and refinement are complementary concepts. Abstraction enables a designer to specify procedure and data and yet suppress low-level

53、 details. Refinement helps the designer to reveal low-level details as design progresses. Both concepts aid the designer in creating a complete design model as the design evolves.</p><p>　　《軟件工程-實踐者的研究方法》<

54、;/p><p>　　Roger S. Pressman博士(340頁-343頁)</p><p><b>　　13.3　設計原則</b></p><p>　　軟件設計是一個過程也是一個模型。設計過程是一個有序的步驟，讓設計者來描述軟件的所要開發(fā)的各個方面。它是非常重要的所以要引起注意，但是，這種設計過程并不是像一個食譜那樣簡單。有創(chuàng)意的技巧，過往的

55、經驗，怎樣把軟件做好的直覺，和對整體質量的負責態(tài)度，都是設計成功的關鍵因素。</p><p>　　設計模型相當于一個建筑師建房子的計劃。所要建設的東西的整體性出現(xiàn)的時候，設計模型也體現(xiàn)出來（例如，一個三維渲染的房子），還會慢慢提煉出一些東西，這些東西為每個建設細節(jié)提供指導（例如，管道布局）。同樣，為軟件創(chuàng)建的設計模型，提供了多種計算機軟件的不同看法。</p><p>　　基本的設計原則，使

56、軟件工程師更好的駕馭設計過程。Davis提出了一系列的軟件設計原則，已經被改編和擴展成下面的幾條：</p><p>　　設計過程不應該陷進“隧道視野”中。一個好的設計師應該在問題要求的基礎上判斷每個方法，并且考慮可替代的方法，這種才智非常適用于軟件開發(fā)，在13.4節(jié)將提出設計概念。</p><p>　　設計應能追溯到分析模型。因為一個單一的模型設計元素經常追溯到多個需求，一種衡量需求被設計

57、模型滿足的程度追蹤方法是必要的。</p><p>　　設計不應該從頭開始。系統(tǒng)采用一套設計模式，其中有許多設計模式可能已經遇到過。這些模式應該選擇作為一種替代再造。時間是短暫的，資源是有限的！設計時間應投資在這些體現(xiàn)真正新理念的東西上面和整合這些已經存在的模式上面。</p><p>　　設計要“減少軟件和現(xiàn)實問題之間的知識距離”。這就是說，軟件設計的結構應該（可能的話）模仿問題域的結構。&

58、lt;/p><p>　　設計應該表現(xiàn)出一致性和集成性。如果一個人開發(fā)整個軟件，設計是一致的。樣式和格式的規(guī)則應該在軟件設計團隊開始設計工作之前定義。設計組件之間的接口如果被考慮到了，這個設計就是具備整體性的。</p><p>　　設計的結構應適應變化。為使設計實現(xiàn)這個原則，設計概念將在下一節(jié)討論。</p><p>　　設計應該被安排得有條不紊，甚至當遇到異常數據，事件，

59、或操作時。設計良好的軟件不應該出現(xiàn)“炸彈”式的反應。它的設計要適應不尋常的情況，如果它必須終止處理，要處理得當而且友好。</p><p>　　設計不是編碼，編碼也不是設計。即使為程序組件創(chuàng)建詳細的程序設計時，設計模型的抽象水平比源代碼更高。在編碼階段進行的唯一的設計決策解決小的實現(xiàn)細節(jié)才能使程序設計被編碼。</p><p>　　設計應當進行質量評估，因為它是被創(chuàng)建的，而不是跟隨事實的。有各

60、種設計概念（第13.4節(jié)）和設計措施（第19和24章），便于協(xié)助設計師進行質量評估。</p><p>　　設計應進行審查，以最小化概念（語義）錯誤。有時有一種傾向是專注于設計審查時的細枝末節(jié)，只見樹木不見森林。一個設計團隊應確保主要的概念設計元素（遺漏，含糊，不一致）在考慮設計模型的語法前已經解決。</p><p>　　當正確應用這些設計原則時，軟件工程師創(chuàng)建了一個具有外在和內在性能的設計

61、。具有良好外部質量的軟件，性能體現(xiàn)在用戶可以很容易地觀察到的地方（例如，速度，可靠性，正確性，可用性）。高質量的內部對于軟件工程師很重要。從技術的角度來看，內部質量直接影響高質量的設計。要實現(xiàn)高質量的內部設計，設計者必須了解基本的設計理念。</p><p><b>　　13.4　設計理念</b></p><p>　　過去四十年來已經發(fā)展了一組基本的軟件設計理念。雖然對

62、每個概念的感興趣的程度多年來有變化，但是每個概念都經受住了時間的考驗。每個概念為軟件設計師提供了一個理論基礎，這些理論基礎可應用于更先進的設計方法。這些概念幫助軟件工程師回答下列問題：</p><p>　　?什么樣的標準可以用來區(qū)分軟件為單個組件？</p><p>　　?函數或數據結構的細節(jié)是如何從軟件的概念表示分離的？</p><p>　　?什么統(tǒng)一的標準定義了一

63、個軟件設計的技術質量？</p><p>　　M.A. Jackson曾經說過：“軟件工程師智慧的開端是意識到正常工作的程序和正確的程序之間的差異”?；镜能浖O計理念提供必要的框架讓“程序正確?！?lt;/p><p><b>　　13.4.1　抽象</b></p><p>　　當我們考慮一個解決任何問題的模塊化方法時，許多多層次的抽象可以被列舉。在

64、最高層次的抽象上，從廣義上講，用問題環(huán)境下的語言來描述解決方案。在較低層次的抽象上，采取更程序化的方向。面向問題的術語加上面向實現(xiàn)的術語共同陳述一個解決方案。最后，在最低級別的抽象上，解決方案以一種可以直接實現(xiàn)的方式陳述。Wasserman提供了一個有用的定義：</p><p>　　心理學上“抽象”的概念允許一個人專注一定程度上的泛化的問題而不考慮無關的低層次的細節(jié)；對于抽象的應用也允許一個人在熟悉的環(huán)境下使用概

65、念和術語工作，而無需把概念和術語轉換成一個陌生的結構……</p><p>　　在軟件運行過程中的每個步驟是軟件解決方案在抽象水平中的細化。在系統(tǒng)工程中，軟件分配一種基于計算機系統(tǒng)的元素。在軟件需求分析中，軟件解決方案被“熟悉的問題環(huán)境”語句陳述。隨著我們在設計過程中向前進，抽象的水平降低。最后，生成源代碼時達到最低抽象層次。</p><p>　　我們將進行不同層次的抽象，我們創(chuàng)建過程和數據

66、抽象。一個程序的抽象是一個命名的指令序列，這個指令序列具有特定的和有限的功能。一個過程抽象的例子是開門的“開”字?！伴_”意味著一個長序列的程序步驟（例如，步行到了門口，伸手抓住旋鈕，旋轉旋鈕，拉門，移步開門，等）。</p><p>　　數據抽象是一個命名的數據集合，用于描述一個數據對象（第12章）。在“開”的程序抽象的背景下，我們可以定義一個數據抽象稱為“門”。如同任何數據對象，“門”的數據抽象，將包括一組描述“

67、門”的屬性（例如，門的類別，擺動方向，開放機制，重量，尺寸）。隨之發(fā)生的是，“開”的過程抽象會利用“門”的數據抽象屬性中包含的信息。</p><p>　　許多現(xiàn)代編程語言提供了一種機制，這種機制能創(chuàng)造抽象的數據類型。例如，Ada包是一種編程語言機制，提供對數據抽象和過程抽象的支持。原來的抽象數據類型被用作模板或通用數據結構，這些通用數據結構是從其他可以被實例化的數據結構中得到的。</p><p

68、>　　控制抽象是軟件設計中使用的第三種形式的抽象。與過程抽象和數據抽象類似，控制抽象意味著程序的控制機制，不指定內部細節(jié)。一個控制抽象的例子是“同步信號量”，它用來協(xié)調操作系統(tǒng)中的活動?？刂瞥橄蟮母拍?，在第14章進行了簡要討論。</p><p><b>　　13.4.2　細化</b></p><p>　　逐步求精是自上而下的設計策略，由尼古拉斯·沃斯最

69、初提出。隨著先后精煉程序細節(jié)的水平提升，一個程序開發(fā)出來。在一個循序漸進的方式中分解一個宏觀的函數聲明（一個過程抽象），直到達到編程語言的語句，層次結構便凸顯出來。Wirth提供的關于這個概念的概述指出：</p><p>　　在（細化的）每個步驟中，給定程序的一個或幾個指令被分解為更詳細的指令。因為任務的細化，所以數據可能要細化，分解，或結構化，細化程序和數據規(guī)格使之一致是自然而然的。</p>&l

70、t;p>　　每一個細化的步驟意味著要進行一些設計決策。程序員知道（設計決策的）相關標準和存在相關標準的替代解決方案是重要的……</p><p>　　Wirth提出的程序細化的過程，類似于需求分析中細化和分割過程?？紤]的實現(xiàn)細節(jié)在水平上不同，方法上相同。</p><p>　　細化其實是一個擬定的過程。我們開始于一個定義在較高抽象層次的函數聲明（或信息的描述）。也就是說，該語句描述功能或