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

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>　　《軟件工程-實(shí)踐者的研究方法》<

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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