結構化設計概念、原理和工具_第1頁
結構化設計概念、原理和工具_第2頁
結構化設計概念、原理和工具_第3頁
結構化設計概念、原理和工具_第4頁
結構化設計概念、原理和工具_第5頁
已閱讀5頁,還剩102頁未讀 繼續免費閱讀

下載本文檔

版權說明:本文檔由用戶提供并上傳,收益歸屬內容提供方,若內容存在侵權,請進行舉報或認領

文檔簡介

1、結構化設計概念、原理和工具 傳統的軟件工程方法學采用結構化設計(Structured Design,SD)技術,完成軟件設計工作,通常把軟件設計工作劃分為概要設計和詳細設計這樣兩個階段。概要設計的主要任務是,通過仔細分析軟件規格說明,適當地對軟件進行功能分解,從而把軟件劃分為模塊,并且設計出完成預定功能的模塊結構。詳細設計階段詳細地設計每個模塊,確定完成每個模塊功能所需要的算法和數據結構。退出4.1 結構化設計與結構化分析的關系4.2 軟件設計的概念和原理4.3 模塊獨立4.4 啟發規則4.5 表示軟件結構的圖形工具4.6 面向數據流的設計方法 4.7 人機界面設計 4.8 過程設計4.9 過

2、程設計的工具4.10 面向數據結構的設計方法4.11 小結4.1 結構化設計與結構化分析的關系 軟件設計必須依據對軟件的需求來進行,結構化分析的結果為結構化設計提供了最基本的輸入信息。 分析模型(見節)的每個元素都提供了創建設計模型時所需要的信息。圖描繪了軟件設計過程中的信息流。由數據模型、功能模型和行為模型清楚地表示的軟件需求被傳送給軟件設計者,他們使用適當的設計方法完成數據設計、體系結構設計、接口設計和過程設計。 在軟件設計期間我們所做出的決策,將最終決定軟件開發能否成功,更重要的是,這些設計決策將決定軟件維護的難易程度。圖4.1 把分析模型轉變成軟件軟件設計的概念和原理 4.2.1 模塊

3、化 模塊是由邊界元素限定的相鄰的程序元素(例如,數據說明,可執行的語句)的序列,而且有一個總體標識符來代表它。像Pascal或Ada這樣的塊結構語言中的Beginend對,或者C,C+和Java語言中的對,都是邊界元素的例子。因此,過程、函數、子程序和宏等,都可作為模塊。面向對象范型中的對象(見第6章)是模塊,對象內的方法也是模塊。模塊是構成程序的基本構件。圖4.2 模塊化和軟件成本 模塊化就是把程序劃分成獨立命名且可獨立訪問的模塊,每個模塊完成一個子功能,把這些模塊集成起來構成一個整體,可以完成指定的功能滿足用戶的需求。 Meyer提出了五條標準,我們可以用這五條標準來評價一種設計方法定義有

4、效的模塊系統的能力。下面列出這五條標準。 (1) 模塊可分解性 如果一種設計方法提供了把問題分解為子問題的系統化機制,它就能降低整個問題的復雜性,從而可以實現一種有效的模塊化解決方案。 (2) 模塊可組裝性 如果一種設計方法能把現有的(可重用的)設計構件組裝成新系統,它就能提供一種并非一切都從頭開始做的模塊化解決方案。 (3) 模塊可理解性 如果可以把一個模塊作為一種獨立單元(無需參考其他模塊)來理解,那么,這樣的模塊是易于構造和易于修改的。 (4) 模塊連續性 如果對系統需求的微小修改只導致對個別模塊,而不是對整個系統的修改,則修改所引起的副作用將最小。 (5) 模塊保護性 如果在一個模塊內

5、出現異常情況時,它的影響局限在該模塊內部,則由錯誤引起的副作用將最小。 采用模塊化原理可以使軟件結構清晰,不僅容易設計也容易閱讀和理解。因為程序錯誤通常局限在有關的模塊及它們之間的接口中,所以模塊化使軟件容易測試和調試,因而有助于提高軟件的可靠性。因為變動往往只涉及少數幾個模塊,所以模塊化能夠提高軟件的可修改性。模塊化也有助于軟件開發工程的組織管理,一個復雜的大型程序可以由許多程序員分工編寫不同的模塊,并且可以進一步分配技術熟練的程序員編寫困難的模塊。 4.2.2 抽象 人類在認識復雜現象的過程中使用的最強有力的思維工具是抽象。人們在實踐中認識到,在現實世界中一定事物、狀態或過程之間總存在著某

6、些相似的方面(共性)。把這些相似的方面集中和概括起來,暫時忽略它們之間的差異,這就是抽象。或者說抽象就是抽出事物的本質特性而暫時不考慮它們的細節。 4.2.3 逐步求精 逐步求精是人類解決復雜問題時采用的基本技術,也是許多軟件工程技術(例如,規格說明技術,設計和實現技術、測試和集成技術)的基礎。可以把逐步求精定義為:“為了能集中精力解決主要問題而盡量推遲對問題細節的考慮。” 求精實際上是細化過程。我們從在高抽象級別定義的功能陳述(或信息描述)開始。也就是說,該陳述僅僅概念性地描述了功能或信息,但是并沒有提供功能的內部工作情況或信息的內部結構。求精要求設計者細化原始陳述,隨著每個后續求精(細化)

7、步驟的完成而提供越來越多的細節。 抽象與求精是一對互補的概念。抽象使得設計者能夠說明過程和數據,同時卻忽略低層細節。事實上,可以把抽象看作是一種通過忽略多余的細節同時強調有關的細節,而實現逐步求精的方法。求精則幫助設計者在設計過程中揭示出低層細節。這兩個概念都有助于設計者在設計演化過程中創造出完整的設計模型。 4.2.4 信息隱藏 應用模塊化原理時,自然會產生的一個問題是:“為了得到最好的一組模塊,應該怎樣分解軟件”。信息隱藏原理指出:應該這樣設計和確定模塊,使得一個模塊內包含的信息(過程和數據)對于不需要這些信息的模塊來說,是不能訪問的。4.3 模塊獨立 “模塊獨立”概念是模塊化、抽象、逐步

8、求精和信息隱藏等概念的直接結果,也是完成有效的模塊設計的基本標準。 模塊的獨立程度可以由兩個定性標準來度量,這兩個標準分別稱為內聚和耦合。耦合衡量不同模塊彼此間互相依賴(連接)的緊密程度;內聚衡量一個模塊內部各個元素彼此結合的緊密程度。以下分別詳細闡述。 4.3.1 耦合 耦合是對一個軟件結構內不同模塊之間互連程度的度量。耦合強弱取決于模塊間接口的復雜程度,進入或訪問一個模塊的點,以及通過接口的數據。 在軟件設計中應該追求盡可能松散耦合的系統。在這樣的系統中可以研究、測試或維護任何一個模塊,而不需要對系統的其他模塊有很多了解。此外,由于模塊間聯系簡單,發生在一處的錯誤傳播到整個系統的可能性就很

9、小。因此,模塊間的耦合程度強烈影響系統的可理解性、可測試性、可靠性和可維護性。 總之,耦合是影響軟件復雜程度的一個重要因素。應該采取下述設計原則: 盡量使用數據耦合,少用控制耦合,限制公共環境耦合的范圍,完全不用內容耦合。 4.3.2 內聚 內聚標志一個模塊內各個元素彼此結合的緊密程度,它是信息隱蔽和局部化概念的自然擴展。簡單地說,理想內聚的模塊只做一件事情。 設計時應該力求做到高內聚,通常中等程度的內聚也是可以采用的,而且效果和高內聚相差不多;但是,低內聚很壞,不要使用。 內聚和耦合是密切相關的,模塊內的高內聚往往意味著模塊間的松耦合。內聚和耦合都是進行模塊化設計的有力工具,但是實踐表明內聚

10、更重要,應該把更多注意力集中到提高模塊的內聚程度上。 事實上,沒有必要精確確定內聚的級別。重要的是設計時力爭做到高內聚,并且能夠辨認出低內聚的模塊,有能力通過修改設計提高模塊的內聚程度降低模塊間的耦合程度,從而獲得較高的模塊獨立性。4.4 啟發規則 軟件工程師們在開發計算機軟件的長期實踐中積累了豐富的經驗,總結這些經驗得出了一些啟發規則。這些啟發規則雖然不像前兩節講述的基本原理那樣普遍適用,但是在許多場合仍然能給軟件工程師有益的啟示,往往能幫助他們找到改進軟件設計提高軟件質量的途徑,因此有助于實現有效的模塊化。下面介紹幾條常用的啟發規則。4.4.1 改進軟件結構提高模塊獨立性4.4.2 模塊規

11、模應該適中4.4.3 深度、寬度、扇出和扇入都應適當4.4.4 模塊的作用域應該在控制域之內4.4.5 力爭降低模塊接口的復雜程度4.4.6 設計單入口單出口的模塊4.4.7 模塊功能應該可以預測圖4.3 模塊的作用域和控制4.5 表示軟件結構的圖形工具 4.5.1 層次圖和HIPO圖 通常使用層次圖描繪軟件的層次結構。在圖中已經非正式地使用了層次圖。在層次圖中一個矩形框代表一個模塊,框間的連線表示調用關系(位于上方的矩形框所代表的模塊調用位于下方的矩形框所代表的模塊)。圖4.4 正文加工系統的層次圖 HIPO圖是美國IBM公司發明的“層次圖加輸入/處理/輸出圖”的英文縮寫。為了使HIPO圖具

12、有可追蹤性,在H圖(即層次圖)里除了頂層的方框之外,每個方框都加了編號。編號方法與本書第3章節中介紹的數據流圖的編號方法相同,例如,把圖44加了編號之后得到圖。圖4.5 正文加工系統的H圖圖4.6 IPO圖的一個例子圖4.7 改進的IPO圖(IPO表)的形式 4.5.2 結構圖 Yourdon提出的結構圖是進行軟件結構設計的另一個有力工具。結構圖和層次圖類似,也是描繪軟件結構的圖形工具,圖中一個方框代表一個模塊,框內注明模塊的名字或主要功能;方框之間的箭頭(或直線)表示模塊的調用關系。 在結構圖中通常還用帶注釋的箭頭表示模塊調用過程中來回傳遞的信息。如果希望進一步標明傳遞的信息是數據還是控制信

13、息,則可以利用注釋箭頭尾部的形狀來區分:尾部是空心圓表示傳遞的是數據,實心圓表示傳遞的是控制信息。圖是結構圖的一個例子。圖4.8 結構圖的例子產生圖4.9 判定為真時調用A,為假時調用B圖4.10 模塊M循環調用模塊A,B,C4.6 面向數據流的設計方法 面向數據流的設計方法的目標是給出設計軟件結構的一個系統化的途徑。 在軟件工程的需求分析階段,信息流是一個關鍵考慮因素,通常用數據流圖描繪信息在系統中加工和流動的情況。面向數據流的設計方法定義了一些不同的“映射”,利用這些映射可以把數據流圖變換成軟件結構。因為任何軟件系統都可以用數據流圖表示,所以面向數據流的設計方法理論上可以設計任何軟件的結構

14、。通常所說的結構化設計方法,也就是基于數據流的設計方法。 4.6.1 概念 面向數據流的設計方法把信息流映射成軟件結構,信息流的類型決定了映射的方法。信息流有下述兩種類型。 1. 變換流 2. 事務流圖4.11 變換流圖4.12 事務流圖4.13 面向數據流方法的設計過程 4.6.2 變換分析 變換分析是一系列設計步驟的總稱,經過這些步驟把具有變換流特點的數據流圖按預先確定的模式映射成軟件結構。下面通過一個例子說明變換分析的方法。 1. 例子2. 設計步驟(1) 復查基本系統模型。(2) 復查并精化數據流圖。(3) 確定數據流圖具有變換特性還是事務特性。(4) 確定輸入流和輸出流的邊界,從而孤

15、立出變換中心。(5) 完成“第一級分解”。(6) 完成“第二級分解”。(7) 使用設計度量和啟發規則對第一次分割得到的軟件結構進一步精化。圖4.14 數字儀表板系統的數據流圖圖4.15 具有邊界的數據流圖圖4.16 第一級分解的方法圖4.17 數字儀表板系統的第一級分解圖4.18 第二級分解的方法圖4.19 未經精化的輸入結構圖4.20 未經精化的變換結構圖4.21 未經精化的輸出結構圖精化后的數字儀表板系統的軟件結構 上述七個設計步驟的目的是,開發出軟件的整體表示。也就是說,一旦確定了軟件結構就可以把它作為一個整體來復查,從而能夠評價和精化軟件結構。在這個時期進行修改只需要很少的附加工作,但

16、是卻能夠對軟件的質量特別是軟件的可維護性產生深遠的影響。 4.6.3 事務分析 雖然在任何情況下都可以使用變換分析方法設計軟件結構,但是在數據流具有明顯的事務特點時,也就是有一個明顯的“發射中心”(事務中心)時,還是以采用事務分析方法為宜。 事務分析的設計步驟和變換分析的設計步驟大部分相同或類似,主要差別僅在于由數據流圖到軟件結構的映射方法不同。 對于一個大系統,常常把變換分析和事務分析應用到同一個數據流圖的不同部分,由此得到的子結構形成“構件”,可以利用它們構造完整的軟件結構。圖4.23 事務分析的映射方法 4.6.4 設計優化 考慮設計優化問題時應該記住,“一個不能工作的最佳設計的價值是值

17、得懷疑的”。軟件設計人員應該致力于開發能夠滿足所有功能和性能要求,而且按照設計原理和啟發式設計規則衡量是值得接收的軟件。 應該在設計的早期階段盡量對軟件結構進行精化。可以導出不同的軟件結構,然后對它們進行評價和比較,力求得到“最好”的結果。這種優化的可能,是把軟件結構設計和過程設計分開的真正優點之一。4.7 人機界面設計 人機界面設計是接口設計的一個組成部分。對于交互式系統來說,人機界面設計和數據設計、體系結構設計、過程設計一樣重要。近年來,人機界面在系統中所占的比例越來越大,在個別系統中人機界面的設計工作量甚至占設計總量的一半以上。 人機界面的設計質量,直接影響用戶對軟件產品的評價,從而影響

18、軟件產品的競爭力和壽命,因此,必須對人機界面設計給以足夠重視。 4.7.1 人機界面設計問題 在設計用戶界面的過程中,幾乎總會遇到下述四個問題:系統響應時間、用戶幫助設施、出錯信息處理和命令交互。 1. 系統響應時間 系統響應時間是許多交互式系統用戶經常抱怨的問題。一般說來,系統響應時間指從用戶完成某個控制動作(例如,按回車鍵或點擊鼠標),到軟件給出預期的響應(輸出或做動作)之間的這段時間。 系統響應時間有兩個重要屬性,分別是長度和易變性。 2. 用戶幫助設施 幾乎交互式系統的每個用戶都需要幫助,當遇到復雜問題時甚至需要查看用戶手冊以尋找答案。大多數現代軟件都提供聯機幫助設施,這使得用戶可以不

19、離開用戶界面就解決自己的問題。 常見的幫助設施有集成的和附加的兩類。 3. 出錯信息處理 出錯信息和警告信息,是出現問題時交互式系統給出的“壞消息”。出錯信息設計得不好,將向用戶提供無用的或誤導的信息,反而增加了用戶的挫折感。 4. 命令交互 命令行曾經是用戶和系統軟件交互的最常用方式,而且也曾經廣泛地用于各種應用軟件中。現在,面向窗口的、點擊和拾取方式的界面已經減少了用戶對命令行的依賴,但是,許多高級用戶仍然偏愛面向命令的交互方式。在多數情況下,用戶既可以從菜單中選擇軟件功能也可以通過鍵盤命令序列調用軟件功能。 4.7.2 人機界面設計過程 用戶界面設計是一個迭代的過程,也就是說,通常先創建

20、設計模型,再用原型實現這個設計模型,并由用戶試用和評估,然后根據用戶的意見進行修改。 4.7.3 界面設計指南 用戶界面設計主要依靠設計者的經驗。總結眾多設計者的經驗而得出的設計指南,有助于設計者設計出友好、高效的人機界面。本節介紹三類人機界面設計指南。 1. 一般交互 一般交互指南涉及信息顯示、數據輸入和整體系統控制,因此,這些指南是全局性的,忽略它們將承擔較大風險。下面敘述一般交互指南。 保持一致性。為人機界面中的菜單選擇、命令輸入、數據顯示以及眾多的其他功能,使用一致的格式。 提供有意義的反饋。向用戶提供視覺的和聽覺的反饋,以保證在用戶和界面之間建立雙向通信。 在執行有較大破壞性的動作之

21、前要求用戶確認。如果用戶要刪除一個文件,或覆蓋一些重要信息,或請求終止一個程序運行,應該給出“您是否確實要”的信息,以請求用戶確認他的命令。 允許取消絕大多數操作。UNDO或REVERSE功能使眾多終端用戶避免了大量時間浪費。每個交互式應用系統都應該能方便地取消已完成的操作。 減少在兩次操作之間必須記憶的信息量。不應該期望用戶能記住一大串數字或名字,以便在下一步操作中使用它們。應該盡量減少記憶量。 提高對話、移動和思考的效率。應該盡量減少擊鍵次數,設計屏幕布局時應該考慮盡量減少鼠標移動的距離,應該盡量避免出現用戶問:“這是什么意思”的情況。 允許犯錯誤。系統應該保護自己不受致命錯誤的破壞。 按

22、功能對動作分類,并據此設計屏幕布局。下拉菜單的一個主要優點就是能按動作類型組織命令。實際上,設計者應該盡力提高命令和動作組織的“內聚性”。 提供對工作內容敏感的幫助設施(參見471節)。 用簡單動詞或動詞短語作為命令名。過長的命令名難于識別和記憶,也會占據過多的菜單空間。 2. 信息顯示 如果人機界面顯示的信息是不完整的,含糊的或難于理解的,則應用軟件顯然不能滿足用戶的需求。可以用多種不同方式“顯示”信息:用文字、圖片和聲音;按位置、移動和大小;使用顏色、分辨率和省略。下面是關于信息顯示的設計指南。 只顯示與當前工作內容有關的信息。用戶在獲得有關系統的特定功能的信息時,不必看到與之無關的數據、

23、菜單和圖形。 不要用數據淹沒用戶,應該用便于用戶迅速地吸取信息的方式來表示數據。例如,可以用圖形或圖表來取代巨大的表格。 使用一致的標記、標準的縮寫和可預知的顏色。顯示的含義應該非常明確,用戶不必參照其他信息源就能理解。 允許用戶保持可視化的語境。如果對圖形顯示進行縮放,原始的圖像應該一直顯示著(以縮小的形式放在顯示屏的一角),以使用戶知道當前觀察的圖像部分在原圖中所處的相對位置。 產生有意義的出錯信息(參見節)。 使用大小寫、縮進和文本分組以幫助理解。人機界面顯示的信息大部分是文字,文字的布局和形式對用戶從中吸取信息的難易程度有很大影響。 使用窗口分隔不同類型的信息。利用窗口用戶能夠方便地“

24、保存”多種不同類型的信息。 使用“模擬”顯示方式表示信息,以使信息更容易被用戶吸取。例如,顯示煉油廠儲油罐的壓力時,如果使用簡單的數字表示壓力,則不易引起用戶注意。但是,如果用類似溫度計的形式來表示壓力,用垂直移動和顏色變化來指示危險的壓力狀況,就能引起用戶的警覺,因為這樣做為用戶提供了絕對和相對兩方面的信息。 高效率地使用顯示屏。當使用多窗口時,應該有足夠的空間使得每個窗口至少都能顯示出一部分。此外,屏幕大小應該選得和應用系統的類型相配套(這實際上是一個系統工程問題)。 3. 數據輸入 用戶的大部分時間用在選擇命令、鍵入數據和向系統提供輸入。在許多應用系統中,鍵盤仍然是主要的輸入介質,但是,

25、鼠標、數字化儀和語音識別系統正迅速地成為重要的輸入手段。下面是關于數據輸入的設計指南。 盡量減少用戶的輸入動作。最重要的是減少擊鍵次數,這可以用下列方法實現:用鼠標從預定義的一組輸入中選一個;用“滑動標尺”在給定的值域中指定輸入值;利用宏把一次擊鍵轉變成更復雜的輸入數據集合。 保持信息顯示和數據輸入之間的一致性。顯示的視覺特征(例如,文字大小、顏色和位置)應該與輸入域一致。 允許用戶自定義輸入。專家級的用戶可能希望定義自己專用的命令或略去某些類型的警告信息和動作確認,人機界面應該允許用戶這樣做。 交互應該是靈活的,并且可調整成用戶最喜歡的輸入方式。用戶類型與喜歡的輸入方式有關,秘書可能非常喜歡

26、鍵盤輸入,而經理可能更喜歡使用鼠標之類的點擊設備。 使在當前動作語境中不適用的命令不起作用。這可使用戶不去做那些肯定會導致錯誤的動作。 讓用戶控制交互流。用戶應該能夠跳過不必要的動作,改變所需做的動作的順序(在應用環境允許的前提下),以及在不退出程序的情況下從錯誤狀態中恢復正常。 對所有輸入動作都提供幫助(參見節)。 消除冗余的輸入。除非可能發生誤解,否則不要要求用戶指定工程輸入的單位;不要要求用戶在整錢數后面鍵入00;盡可能提供缺省值;絕對不要要求用戶提供程序可以自動獲得或計算出來的信息。4.8 過程設計 過程設計應該在數據設計、體系結構設計和接口設計完成之后進行,它是詳細設計階段應該完成的

27、主要任務。 過程設計的任務還不是具體地編寫程序,而是要設計出程序的“藍圖”,以后程序員將根據這個藍圖寫出實際的程序代碼。因此,過程設計的結果基本上決定了最終的程序代碼的質量。考慮程序代碼的質量時必須注意,程序的“讀者”有兩個,那就是計算機和人。 在軟件的生命周期中,設計測試方案,診斷程序錯誤,修改和改進程序等都必須首先讀懂程序。實際上對于長期使用的軟件系統而言,人讀程序的時間可能比寫程序的時間還要長得多。因此,衡量程序的質量不僅要看它的邏輯是否正確,性能是否滿足要求,更主要的是要看它是否容易閱讀和理解。過程設計的目標不僅僅是邏輯上正確地實現每個模塊的功能,更重要的是設計出的處理過程應該盡可能簡

28、明易懂。結構程序設計技術是實現上述目標的關鍵技術,因此是過程設計的邏輯基礎。圖424三種基本的控制結構(a) 順序結構,先執行A再執行B;(b) IF-THEN-ELSE型選擇(分支)結構;(c)DO-WHILE型循環結構 結構程序設計的經典定義如下所述。 如果一個程序的代碼塊僅僅通過順序、選擇和循環這三種控制結構進行連接,并且每個代碼塊只有一個入口和一個出口,則稱這個程序是結構化的。 這個經典定義過于狹隘了,結構程序設計本質上并不是無GO TO語句的編程方法,而是一種使程序代碼容易閱讀、容易理解的編程方法。在大多數情況下,無GO TO的代碼確實是容易閱讀、容易理解的代碼,但是,在某些情況下,

29、為了達到容易閱讀和容易理解的目的,反而需要使用GO TO語句。例如,當出現了錯誤條件時,重要的是在數據庫崩潰或棧溢出之前,盡可能快地從當前程序退到一個出錯處理程序,實現這個目標的最好方法就是使用前向GO TO語句(或與之等效的專用語句),機械地使用三種基本控制結構實現這個目標反而會使程序晦澀難懂。因此,下述的結構程序設計的定義可能更全面一些。 結構程序設計是盡可能少用GO TO語句的程序設計方法。最好僅在檢測出錯誤時才使用GO TO語句,而且應該總是使用前向GO TO語句。 如果只允許使用順序、IF-THEN-ELSE型分支和DO-WHILE型循環這三種基本控制結構,則稱為經典的結構程序設計;

30、如果除了上述三種基本控制結構之外,還允許使用DO-CASE型多分支結構和DO-UNTIL型循環結構,則稱為擴展的結構程序設計;如果再加上允許使用LEAVE(或BREAK)結構,則稱為修正的結構程序設計。圖425其他常用的控制結構(a) DO-UNTIL型循環結構;(b)多分支結構4.9 過程設計的工具 描述程序處理過程的工具稱為過程設計的工具,它們可以分為圖形、表格和語言三類。 4.9.1 程序流程圖 程序流程圖又稱為程序框圖,它是歷史最悠久使用最廣泛的描述過程設計的方法,然而它也是用得最混亂的一種方法。 圖中列出了程序流程圖中使用的各種符號。 圖4.26 程序流程圖中使用的符號(a) 選擇(

31、分支);(b) 注釋;(c) 預先定義的處理;(d) 多分支;(e) 開始或停止;(f) 準備;(g)循環上界限;(h) 循環下界限;(i) 虛線;(j) 省略符;(k) 并行方式;(l) 處理;(m) 輸入/輸出;(n) 連接;(o) 換頁連接;(p) 控制流 4.9.2 盒圖(N-S圖) 出于要有一種不允許違背結構程序設計精神的圖形工具的考慮,Nassi和Shneiderman提出了盒圖,又稱為N-S圖。 圖給出了結構化控制結構的盒圖表示,也給出了調用子程序的盒圖表示方法。 盒圖沒有箭頭,因此不允許隨意轉移控制。堅持使用盒圖作為詳細設計的工具,可以使程序員逐步養成用結構化的方式思考問題和解

32、決問題的習慣。 圖4.27 盒圖的基本符號(a) 順序;(b) IF-THEN-ELSE型分支;(c) CASE型多分支;(d) 循環;(e) 調用子程序A 4.9.3 PAD圖 PAD是問題分析圖(Problem Analysis Diagram)的英文縮寫,自1973年由日本日立公司發明以后,已得到一定程度的推廣。它用二維樹形結構的圖來表示程序的控制流,將這種圖翻譯成程序代碼比較容易。圖給出PAD圖的基本符號。圖圖的基本符號(a) 順序(先執行P1后執行P2);(b) 選擇(IF C THEN P1 ELSE P2);(c) CASE型多分支;(d) WHILE型循環(WHILE C DO

33、 P);(e) UNTIL型循環(REPEAT P UNTIL C);(f) 語句標號;(g) 定義圖4.29 使用PAD圖提供的定義功能來逐步求精的例子(a) 初始的PAD圖;(b) 使用def符號細化處理框P2 4.9.4 判定表 當算法中包含多重嵌套的條件選擇時,用程序流程圖、盒圖、PAD圖或后面即將介紹的過程設計語言(PDL)都不易清楚地描述。然而判定表卻能夠清晰地表示復雜的條件組合與應做的動作之間的對應關系。 一張判定表由四部分組成,左上部列出所有條件,左下部是所有可能做的動作,右上部是表示各種條件組合的一個矩陣,右下部是和每種條件組合相對應的動作。判定表右半部的每一列實質上是一條規

34、則,規定了與特定的條件組合相對應的動作。 4.9.5 判定樹 判定表雖然能清晰地表示復雜的條件組合與應做的動作之間的對應關系,但其含義卻不是一眼就能看出來的,初次接觸這種工具的人要理解它需要有一個簡短的學習過程。此外,當數據元素的值多于兩個時(例如,節例子中假設對機票需細分為頭等艙、二等艙和經濟艙等多種級別時),判定表的簡潔程度也將下降。 判定樹是判定表的變種,也能清晰地表示復雜的條件組合與應做的動作之間的對應關系。圖4.30 用判定樹表示計算行李費的算法 4.9.6 過程設計語言(PDL) PDL也稱為偽碼,這是一個籠統的名稱,現在有許多種不同的過程設計語言在使用。它是用正文形式表示數據和處

35、理過程的設計工具。 PDL具有嚴格的關鍵字外部語法,用于定義控制結構和數據結構;另一方面,PDL表示實際操作和條件的內部語法通常又是靈活自由的,以便可以適應各種工程項目的需要。因此,一般說來PDL是一種“混雜”語言,它使用一種語言(通常是某種自然語言)的詞匯,同時卻使用另一種語言(某種結構化的程序設計語言)的語法。4.10 面向數據結構的設計方法 在許多應用領域中信息都有清楚的層次結構、輸入數據、內部存儲的信息(數據庫或文件)以及輸出數據都可能有獨特的結構。數據結構既影響程序的結構又影響程序的處理過程,重復出現的數據通常由具有循環控制結構的程序來處理,選擇數據(即,可能出現也可能不出現的信息)

36、要用帶有分支控制結構的程序來處理。層次的數據組織通常和使用這些數據的程序的層次結構十分相似。 面向數據結構的設計方法的最終目標是得出對程序處理過程的描述。這種設計方法并不明顯地使用軟件結構的概念,模塊是設計過程的副產品,對于模塊獨立原理也沒有給予應有的重視。因此,這種方法最適合于在詳細設計階段使用,也就是說,在完成了軟件結構設計之后,可以使用面向數據結構的方法來設計每個模塊的處理過程。 4.10.1 Jackson圖 雖然程序中實際使用的數據結構種類繁多,但是它們的數據元素彼此間的邏輯關系卻只有順序、選擇和重復三類,因此,邏輯數據結構也只有這三類。 1. 順序結構 順序結構的數據由一個或多個數

37、據元素組成,每個元素按確定次序出現一次。圖是表示順序結構的Jackson圖的一個例子。圖4.31 A由B、C、D三個元素順序組成(每個元素只出現一次,出現的次序依次是B、C和D) 2. 選擇結構 選擇結構的數據包含兩個或多個數據元素,每次使用這個數據時按一定條件從這些數據元素中選擇一個。圖是表示三個中選一個結構的Jackson圖。圖4.32 根據條件A是B或C或D中的某一個(注意:在B、C和D的右上角有小圓圈做標記) 3. 重復結構 重復結構的數據,根據使用時的條件由一個數據元素出現零次或多次構成。圖433是表示重復結構的Jackson圖。圖4.33 A由B出現N次(N0)組成(注意:在B的右

38、上角有星號標記) 4.10.2 改進的Jackson圖 4.10.3 Jackson方法 Jackson結構程序設計方法基本上由下述五個步驟組成。 (1) 分析并確定輸入數據和輸出數據的邏輯結構,并用Jackson圖描繪這些數據結構。 (2) 找出輸入數據結構和輸出數據結構中有對應關系的數據單元。所謂有對應關系是指有直接的因果關系,在程序中可以同時處理的數據單元(對于重復出現的數據單元必須重復的次序和次數都相同才可能有對應關系)。圖改進的Jackson圖(a) 順序結構,B、C、D中任一個都不能是選擇出現或重復出現的數據元素(即,不能是右上角有小圓或星號標記的元素);(b) 選擇結構,S右面括

39、號中的數字i是分支條件的編號;(c) 可選結構,A或者是元素B或者不出現(可選結構是選擇結構的一種常見的特殊形式);(d) 重復結構,循環結束條件的編號為i。 (3) 用下述三條規則從描繪數據結構的Jackson圖導出描繪程序結構的Jackson圖。 第一,為每對有對應關系的數據單元,按照它們在數據結構圖中的層次在程序結構圖的相應層次畫一個處理框(注意,如果這對數據單元在輸入數據結構和輸出數據結構中所處的層次不同,則和它們對應的處理框在程序結構圖中所處的層次與它們之中在數據結構圖中層次低的那個對應)。 第二,根據輸入數據結構中剩余的每個數據單元所處的層次,在程序結構圖的相應層次分別為它們畫上對應的處理框。 第三,根據輸出數據結構中剩余的每個數據單元所處的層次,在

溫馨提示

  • 1. 本站所有資源如無特殊說明,都需要本地電腦安裝OFFICE2007和PDF閱讀器。圖紙軟件為CAD,CAXA,PROE,UG,SolidWorks等.壓縮文件請下載最新的WinRAR軟件解壓。
  • 2. 本站的文檔不包含任何第三方提供的附件圖紙等,如果需要附件,請聯系上傳者。文件的所有權益歸上傳用戶所有。
  • 3. 本站RAR壓縮包中若帶圖紙,網頁內容里面會有圖紙預覽,若沒有圖紙預覽就沒有圖紙。
  • 4. 未經權益所有人同意不得將文件中的內容挪作商業或盈利用途。
  • 5. 人人文庫網僅提供信息存儲空間,僅對用戶上傳內容的表現方式做保護處理,對用戶上傳分享的文檔內容本身不做任何修改或編輯,并不能對任何下載內容負責。
  • 6. 下載文件中如有侵權或不適當內容,請與我們聯系,我們立即糾正。
  • 7. 本站不保證下載資源的準確性、安全性和完整性, 同時也不承擔用戶因使用這些下載資源對自己和他人造成任何形式的傷害或損失。

評論

0/150

提交評論