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

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　設(shè)計原則</b></p><p>　　軟件設(shè)計是一個過程也是一個模型。設(shè)計過程是一個有序的步驟，讓設(shè)計者來描述軟件的所要開發(fā)的各個方面。它是非常重要的所以要引起注意，但是，這種設(shè)計過程并不是像一個食譜那樣簡單。有創(chuàng)意的技巧，過往的

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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