軟件設計基礎

是后續開發步驟及軟件維護工作的基礎。如果沒有設計，只能建立一個不穩定的系統結構軟件設計：第2頁,共82頁，2024年2月25日，星期天軟件工程第7章軟件設計基礎概念基本概念設計過程設計工具說明與評審第3頁,共82頁，2024年2月25日，星期天7.1.1軟件設計過程TextText技術角度與管理角度詳細設計概要設計過程設計數據設計結構設計概要設計根據需求確定軟件和數據的總體框架詳細設計將“概設”結果進一步精化成算法表示和數據結構結構設計確定程序各主要部件之間的關系數據設計把信息描述轉換為實現軟件所要求的數據結構過程設計完成每一部件的過程化描述第4頁,共82頁，2024年2月25日，星期天7.1.2抽象與逐步求精抽象抽出事務的本質特性而暫時不考慮它們的細節。是控制復雜性的基本策略。定義需求設計實現軟件系統被描述為基于計算機的大系統的一個組成部分軟件用問題域約定的習慣用語表達概要設計過渡到詳細設計時，抽象級再一次降低編碼完成后達到了抽象的最低級過程抽象把完成一個特定功能的動作序列抽象為一個過程名和參數表數據抽象把一個數據對象的定義（或描述）抽象為一個數據類型名第5頁,共82頁，2024年2月25日，星期天抽象1：該CAD軟件系統配有與繪圖員進行可視化通信的圖形界面，能用鼠標代替繪圖工具畫各種直線和曲線；能完成所有幾何計算以及所有截面視圖和輔助視圖的設計。圖形設計的結果保存在圖形文件中，圖形文件可以包含幾何的、正文的和其他各種補充設計信息。例7.1考慮適用于低級CAD的圖形軟件包CAD軟件任務創建二維圖形管理圖形文件用戶界面顯示圖形任務抽象2：

CAD軟件任務；用戶界面子任務；創建二維圖形子任務；顯示圖形子任務；管理圖形文件子任務；

endCAD.抽象3（僅以“創建二維圖形任務”為例）

PROCEDURE創建二維圖形

REPEATUNTIL<創建圖形任務終止>……ENDREPETITION;ENDPROCEDURE.;DOWHILE<出現與數字儀的交互時>

數字儀接口任務；判斷作圖請求；線：畫線任務；圓：畫圓任務；

……END;

DOWHILE<出現與鍵盤的交互時>

鍵盤接口任務；選擇分析或計算；輔助視圖：輔助視圖任務；截面視圖：截面視圖任務；

……END;第6頁,共82頁，2024年2月25日，星期天數據對象：

TYPEdrawing

ISSTRUCTUREDEFINEDnumberISSTRINGLENTH(12);

geometryDEFINED…notesISSTRINGLENTH(256);

bomDEFINED…ENDdrawingTYPE;數據抽象blueprintISINSTANCEOFdrawing;

或schematicISINSTANCEOFdrawing;

第7頁,共82頁，2024年2月25日，星期天逐步求精逐步求精為了能集中精力解決主要問題而盡量推遲對問題細節的考慮抽象求精第8頁,共82頁，2024年2月25日，星期天7.1.3模塊化與信息隱藏模塊理論依據理想的屬性大小I/O、功能，程序、數據程序、程序段、子程序一個功能、易理解、獨立例：庫存管理系統的模塊劃分事務接收模塊更新庫存清單訂貨處理生成報表例：人事管理系統輸入職工檔案職工檔案管理系統生成職工檔案報表系統最小成本區域MO軟件總成本用于接口的成本每個模塊成本之和模塊總數成本或工作量信息隱藏內聚度耦合度分治法：C(P1+P2)>C(P1)+C(P2)E(P1+P2)>E(P1)+E(P2第9頁,共82頁，2024年2月25日，星期天 有人說，模塊化是為了使一個復雜的大型程序能被人的智力所管理，軟件應該具備的唯一屬性。如果一個大型程序僅由一個模塊組成，它將很難被入所理解。下面根據人類解決問題的一般規律，論證上面的結論。 設函數C（x）定義問題x的復雜程度，函數E（x）確定解決問題x需要的工作量（時間）。對于兩個問題Pl和P2，如果

C（P1）＞C（P2）即P1比P2復雜，顯然E（PI）＞E（P2）即問題越復雜，所需的工作量越大。根據人類解決一般問題的經驗，另一個有趣的規律是

C（P1十P2）＞C（PI）十C（P2）也就是說，如果一個問題由Pl和P2兩個問題組合而成那么它的復雜程序大于分別考慮每個問題時的復雜程度之和。綜上所述，得到下面的不等式

E（Pl十P2）＞E（PI）十E（P2）第10頁,共82頁，2024年2月25日，星期天 這個不等式導致“各個擊破”的結論——把復雜的問題分解成許多容易解決的小問題，原來的問題也就容易解決了。這就是模塊化的根據。由上面的不等式似乎還能得出下述結論：如果無限地分割軟件，最后為了開發軟件而需要的工作量也就小得可以忽略了。事實上，還有另一個因素在起作用，從而使得上述結論不能成立。參看上圖，當模塊數目增加時每個模塊的規模將減小，開發單個模塊需要的成本（工作量）確實減少了；但是，隨著模塊數目增加，設計模塊問接口所需要的工作量也將增加。根據這兩個因素，得出了圖中的總成本曲線。每個程序都相應地有一個最適當的模塊數目M，使得系統的開發成本最小。雖然目前我們還不能精確地決定M的數值，但是在考慮模塊化的時候總成本曲線確實是有用的指南。

第11頁,共82頁，2024年2月25日，星期天信息隱藏模塊內所含信息對那些不需要這些信息的模塊不可訪問，每個模塊只完成一個相對獨立的特定功能。應用模塊化原理時，自然會產生的一個問題是：“為了得到最好的一組模塊，應該怎樣分解軟件呢?”信息隱蔽原理指出：應該這樣設計和確定模塊，使得一個模塊內包含的信息（過程和數據）對于不需要這些信息的模塊來說，是不能訪問的。局部化的概念和信息隱蔽概念是密切相關的。所謂局部化是指把一些關系密切的軟件元素物理地放得彼此靠近。在模塊中使用局部數據元素是局部他的一個例子。顯然，局部化有助于實現信息隱蔽。“隱蔽”意味著有效的模塊化可以通過定義一組獨立的模塊而實現，這些獨立的模塊彼此間僅僅交換那些為了完成系統功能而必須交換的信息。第12頁,共82頁，2024年2月25日，星期天信息隱藏如果在測試期間和以后約軟件維護期間需要修改軟件，那么使用信息隱蔽原理作為模塊化系統設計的標準就會帶來極大好處。因為絕大多數數據和過程對于軟件的其他部分而言是隱蔽的（也就是“看”不見的），在修改期間由于疏忽而引入的錯誤就很少可能傳播到軟件的其他部分。第13頁,共82頁，2024年2月25日，星期天模塊獨立性(Moduleindependence)好設計的關鍵：每個模塊完成一個相對獨立的子功能，并且與其它模塊間的接口簡單。模塊獨立的概念是模塊化、抽象、信息隱蔽和局部化概念的直接結果。開發具有獨立功能而且和其他模塊之間沒有過多的相互作用的模塊，就可以做到模塊獨立。換句話說，希望這樣設計軟件結構，使得每個模塊完成一個相對獨立的特定子功能，并且和其他模塊之間的關系很簡單。模塊獨立性第14頁,共82頁，2024年2月25日，星期天為什么模塊的獨立性很重要呢?主要有兩條理由：第一，有效的模塊化（即具有獨立的模塊）的軟件比較容易開發出來。這是由于能夠分割功能而且接口可以簡化，當許多人分工合作開發同一個軟件時，這個優點尤其重要。第二，獨立的模塊比較容易測試相維護。這是因為相對說來，修改設計和程序需要的工作量比較小，錯誤傳播范圍小，需要擴充功能時能夠“插入”模塊。總之，模塊獨立是好設計的關鍵，而設計又是決定軟件質量的關鍵環節。模塊獨立性第15頁,共82頁，2024年2月25日，星期天獨立性的度量：耦合(Coupling)&內聚(Cohesion)模塊的獨立程度可以由兩個定性標準度量，這兩個標準分別稱為內聚和耦合。耦合衡量不同模塊彼此間互相依賴（連接）的緊密程度；內聚衡量一個模塊內部各個元素彼此結合的緊密程度。以下分別詳細闡述。第16頁,共82頁，2024年2月25日，星期天內聚標志一個模塊內各個元素被此結合的緊密程度，它是信息隱蔽和局部化概念的自然擴展。簡單地說，理想內聚的模塊只做一件事情。設計時應該力求做到高內聚，通常中等程度的內聚也是可以采用的，而且效果和高內聚相差不多；但是，低內聚很壞，不要使用。第17頁,共82頁，2024年2月25日，星期天低級內聚度（3個）一個模塊內各成分為完成一組功能而組合在一起，它們相互之間即使有關系，也很松散。1偶然有時在寫完一個程序之后，發現一組語句在兩處或多處出現，于是把這些語句作為一個模塊以節省內存，這樣就出現了偶然內聚的模塊第18頁,共82頁，2024年2月25日，星期天一個模塊完成的諸任務邏輯上相關

2邏輯讀入分數平均/最高？計算平均分計算最高分輸出結果例如一個計算全部同學平均分和最高分的模塊。無論計算哪種分數，都要經過讀入全班學生分數，進行計算，輸出計算結果等步驟。實際上除中間的一步須按不同的方法計算外，前、后這兩步都是相同的。把這兩種在邏輯上相似的功能放在一個模塊中，就可以省去程序中的重復部分。缺點是執行中要從模塊外引入用作判斷的開關鍵，從而增加了塊間的耦合第19頁,共82頁，2024年2月25日，星期天如果一個模塊包含的諸任務必須在同一時間段內執行。例如一個初始化模塊3時間A:Readinputsfromdiskfromtapefrom……第20頁,共82頁，2024年2月25日，星期天在偶然內聚的模塊中，各種元素之間沒有實質性聯系，很可能在一種應用場合需要修改這個模塊，在另一種應用場合又不允許這種修改，從而陷入困境。事實上，偶然內聚的模塊出現修改錯誤的概率比其他類型的模塊高得多。在邏輯內聚的模塊中，不同功能混在一起，合用部分程序代碼，即使局部功能的修改有時也會影響全局。因此．這類模塊的修改也比較困難。時間關系在一定程度上反映了程序的某些實質，所以時間內聚比邏輯內聚好一些。這三種內聚為低內聚。第21頁,共82頁，2024年2月25日，星期天中級內聚度（2個）模塊內成分彼此相關，并且必須按特定的次序執行4過程enterdatacheckdatamanipulatedata循環體計算累積事務記錄累積銷售額累積訂貨量循環傳送事務記錄給計算累積模塊，得到累積訂貨量之后，也得到了累積銷售量。第22頁,共82頁，2024年2月25日，星期天模塊中各成分都將對數據結構的同一區域進行操作，即如果模塊中所有元素都使用同一個輸入數據和（或）產生同一個輸出數據，則稱為通信內聚。5通信模塊A從文件FILE讀出數據1.由數據產生報表一2.由數據產生報表二開領書單登記售書售書登記表領書單發票修改刪除文件第23頁,共82頁，2024年2月25日，星期天高級級內聚度（2個）模塊內的各處理成分均與同一功能相關，且這些處理必須順序執行6順序這類模塊中的各組成部分是順序執行的。在通常情況下，上一個處理框的輸出就是下一個處理框的輸入。建立方程組系數矩陣高斯消除法回代第24頁,共82頁，2024年2月25日，星期天模塊內所有成分形成一個整體，完成單個功能7功能1.輸入系數2.求方程的根3.打印方程的根求一元二次方程根的模塊第25頁,共82頁，2024年2月25日，星期天七種“內聚模塊”的性能比較

形式評價可修改性可讀性黑箱程度通用性偶然最壞最壞最壞黑箱好邏輯最壞最壞不好不完全黑好時間不好不好中不完全黑中過程中中中半透明不好通信中中中半透明不好順序好好好透明最壞功能好好好透明最壞第26頁,共82頁，2024年2月25日，星期天耦合是對一個軟件結構內不同模塊之間互連程度的度量。耦合強弱取決于模塊間接口的復雜程度，進入或訪問一個模塊的點，以及通過接口的數據。在軟件設計中應該追求盡可能松散耦合的系統。在這樣的系統中可以研究、測試或維護任何一個模塊，而不需要對系統的其他模塊有很多了解。此外，由于模塊間聯系簡單，發生在一處的錯誤傳播到整個系統的可能性就很小。因此，模塊間的耦合程度強烈影響系統的可理解性、可測試性、可靠性和可維護性。GreatdealofdependenceIndependentHighlycoupled

LooselycoupledUncoupled

第27頁,共82頁，2024年2月25日，星期天模塊間的耦合

耦合：表示一個軟件結構內各個模塊之間的互連程度，盡量選用松散耦合的系統1.非直接耦合：兩個模塊中任一個，都不依賴于對方能獨立工作。如果兩個模塊中的每一個都能獨立地工作而不需要另一個模塊的存在，那么它們彼此完全獨立，這意味著模塊間無任何連接，耦合程度最低，模塊的獨立性最高。見圖中的模塊1和模塊2的關系。它們之間是同級模塊，互相之間沒有信息的傳統。但是，在一個軟件系統中不可能所有模塊之間都沒有任何連接。1.非直接耦合--—2.數據耦合模塊1模塊2非直接耦合模塊3第28頁,共82頁，2024年2月25日，星期天模塊間的耦合1.非直接耦合--—2.數據耦合2.數據耦合兩個模塊間通過參數交換信息，而信息僅限于數據開發貨單計算金額單價數量金額第29頁,共82頁，2024年2月25日，星期天3.特征耦合計算水費和電費計算水費計算電費住戶詳情水費住戶詳情電費計算水量和電費計算水費計算電費水費電費本月用水量本月用電量

住戶詳情數據結構中包括：

“本月用水量”、“本月用電量”。“特征耦合”圖可改進“數據耦合”圖如果兩個模塊都與同一個數據結構有關，則為特征耦合。第30頁,共82頁，2024年2月25日，星期天4.當模塊A向模塊B所傳遞的信息控制了B的內部邏輯。4.控制耦合讀入分數平均/最高？計算平均分計算最高分輸出結果當調用這一模塊時，調用模塊必須先把一個控制信號（平均分/最高分）傳遞給它，以便選擇所需操作。因此必須知道被控模塊的的內部結構，從而增加了模塊間的相互依賴。第31頁,共82頁，2024年2月25日，星期天5.外部耦合5.若干模塊均與同一個外部環境關聯。如：I/O、格式、通信協議。一組模塊都訪問同一全局變量而不是同一全局數據結構就是外部耦合。第32頁,共82頁，2024年2月25日，星期天

6.公共耦合----7.內容耦合(病態耦合)6.如果兩個模塊都和同一個公共數據域有關，即一組模塊都訪問同一全局數據結構就是公共耦合ABC公用數據第33頁,共82頁，2024年2月25日，星期天7.一個模塊和另一個模塊的內部屬性有關(運行程序和內部數據)。如：一個模塊使用另一個模塊內部的數據或控制信息；一個模塊直接轉移到另一個模塊。模塊A中TRC：模塊B中GOTOTRC第34頁,共82頁，2024年2月25日，星期天設計模塊時，應以數據耦合為主，輔以特征耦合與控制耦合，消除公共耦合和內容耦合。七種“耦合模塊”的性能比較

耦合方式對連鎖反應的影響可修改性可讀性通用性非直接弱好好好數據弱好好好特征弱中中中控制中不好不好不好外部中不好不好不好公共強不好最壞最壞內容最強最壞最壞最壞第35頁,共82頁，2024年2月25日，星期天耦合、內聚與模塊獨立性的關系第36頁,共82頁，2024年2月25日，星期天7.1.4軟件總體結構設計（softwarearchitecture）目標：模塊化的程序結構、明確各模塊之間的控制關系、說明程序的輸入輸出數據流、進一步協調程序結構和數據結構。軟件結構組成系統中所有過程性部件(即模塊)構成的層次結構(即程序結構)對應于程序結構的輸入輸出數據結構第37頁,共82頁，2024年2月25日，星期天結構設計原則第38頁,共82頁，2024年2月25日，星期天結構設計原則2.模塊規模適中：過大不易理解；太小則接口開銷過大。注意分解后不應降低模塊的獨立性。提高模塊獨立性爭取低耦合、高內聚（增加內聚>減少耦合）第39頁,共82頁，2024年2月25日，星期天

深度=分層的層數。過大表示分工過細。

寬度=同一層上模塊數的最大值。過大表示系統復雜度大。3.選擇適當的深度、寬度、扇出和扇入第40頁,共82頁，2024年2月25日，星期天

扇出=一個模塊直接調用\控制的模塊數。3fan-out9AA的扇出AA的扇入

扇入=直接調用該模塊的模塊數在不破壞獨立性的前提下，fan-in

大的比較好。第41頁,共82頁，2024年2月25日，星期天4作用域在控制域內MACB例如：M的控制域為{M，A，B，C}

模塊控制域：模塊本身和其下級模塊（即可供它調用的模塊）模塊作用域：受這個模塊中判定所影響的模塊。本規則的含義是：（1）作用域不要超出控制域的范圍（2）軟件系統的判定，其位置離受它控制的模塊越近越好第42頁,共82頁，2024年2月25日，星期天A:

…………if……thengotoB1……………………B:……………………B1:……………………作用域在控制域內A:…………if……thengotoM1……………………M:……………………M1:gotoC1……………………作用域超出了控制域上例右邊中A的作用超出了控制域。改進方法之一，可以把A中的if

移到M中；方法之二，可以把C移到A下面。第43頁,共82頁，2024年2月25日，星期天5、降低接口的復雜程度：接口復雜可能表明模塊的獨立性差。6、單出單入，避免內容耦合。7、模塊功能可預測——相同輸入必產生相同輸出。反例：模塊中使用全局變量或靜態變量，則可能導致不可預測。第44頁,共82頁，2024年2月25日，星期天7.2軟件過程設計技術和工具結構化程序設計是程序設計技術，它采用自頂向下逐步求精的設計方法和單入口單出口的控制構件。

結構化設計圖形表示法盒圖流程圖判定樹判定表7.2.1結構化程序設計第45頁,共82頁，2024年2月25日，星期天7.2.2圖形表示法1．流程圖（也稱為程序框圖）是最常用的一種表示法，“順序”、“分支”和“循環”三個基本控制構件用流程圖表達的形式如圖8-2-1所示。F第二個任務順序結構then部分else部分do?while循環第一個任務T分支條件If?then?else結構循環條件循環體TF圖8-2-1流程圖構件第46頁,共82頁，2024年2月25日，星期天7.2.2圖形表示法2．盒圖也稱為N-S圖或Chapin圖。這種表達方式取消了流程線，它強迫程序員以結構化方式思考和解決問題。第一個任務第二個任務第三個任務順序結構else部分then部分條件FTif-then-else結構do-while部分循環條件循環結構圖8-2-3盒圖的構件第47頁,共82頁，2024年2月25日，星期天3．PAD圖問題分析圖（ProblemAnslysisDiagram，簡稱PAD圖），是由日本日立公司的二村良彥等人于1973年提出的，它用二維樹圖形表示程序流程，是一種改進的圖形描述方式，完全支持SP方法。近年來在軟件開發中得到了廣泛使用，并且越來越受到人們的贊賞。

PAD因的基本符號見下圖。第48頁,共82頁，2024年2月25日，星期天第49頁,共82頁，2024年2月25日，星期天與其它的詳細設計描述工具相比，問題分標圖具有以下優點：（1）用PAD圖表達的程序過程呈樹形結構，這種圖容易翻譯成程序代碼。（2）用PAD圖描繪的程序結構清晰。圖中最左邊的豎線是程序的主線，表示第一層結構。隨著程序層次的增加，PAD圖逐漸向右延伸，每增加一個層次，圖形向右擴展一條豎線。PAD圖中豎線的總條數就是程序的層次數。（3）用PAD圖表達程序邏輯，易讀、易懂、易記。PAD圖是二維樹形結構，從圖中最左邊的豎線上端的結點開始，自上而下、自左至右順序執行，遍歷所有的結點。第50頁,共82頁，2024年2月25日，星期天（4）PAD圖既可描述程序，又可描繪數據結構。（5）PAD圖完全支持自頂向下、逐步求精的結構化方法。開始設計時設計者可以定義一個抽象的程序，隨著設計工作的深入，通過使用定義符號（def）逐步增加細節，直到完成詳細設計。（6）沿著PAD的外邊輪廓機械地走一遍，俗稱“走樹”，可以方便地實現編程。這步工作可由人工完成，也可以利用PAD自動生成程序完成。PAD圖為COBOL、FORTRAN和PASCAL等高級語言都提供了一套相應的圖形符號，每種控制語句都有一個圖形符號與之對應。所以，很容易將PAD圖轉換成高級語言源程序。這是PAD圖的最大的優點之一。第51頁,共82頁，2024年2月25日，星期天7.2.3判定表與判定樹判定表由四部分組成：左上部列出所有條件左下部列出所有可能的動作右上部所有可能的條件組合（矩陣）右下部條件組合與動作之間的對應關系用于：條件復雜，根據這些條件的組合選擇動作判定表的每一列可解釋為一條處理規則第52頁,共82頁，2024年2月25日，星期天7.2.3判定表與判定樹【例7.2】問題處理描述：耗電記費系統可以采用固定價格收費、浮動價格收費和其他方式收費三種方式。若采用固定價格方式收費，對每月耗電100kW?h以下的用戶只征收最低標準費，超過100kW?h的用戶按價格A收費；若采用浮動價格方式收費，則每月耗電100kW?h以下的用戶按價格A收費，超過100kW?h的用戶按價格B收費。第53頁,共82頁，2024年2月25日，星期天表7?1判定表規則12345固定價格方式浮動價格方式耗電＜100kW.h

耗電≥100kW.hTFTFTFFTFTTFFTFTFF收取最低標準費按價格A收費按價格B收費其他處理√√√√√條件動作第54頁,共82頁，2024年2月25日，星期天【例7.2】判定樹

耗電＜100kW·h—收取最低標準費固定方式耗電≥100kW·h—按價格A收費耗電＜100kW·h—按價格A收費耗電收費浮動方式耗電≥100kW·h—按價格表B收費其他方式—其他處理圖8-2-5用判定樹表示計算耗電收費的算法第55頁,共82頁，2024年2月25日，星期天7.2.3判定表與判定樹判定樹的優點：形式簡單，直觀明了，易于掌握。判定樹的缺點：①存在著數據冗余的問題，相同的數據元素往往要重復多次，而且越接近樹的葉端重復的次數越多。②判定樹要求對條件進行層次劃分，若條件所處層次不對，可能會導致增加判定樹的復雜性。第56頁,共82頁，2024年2月25日，星期天7.2.4過程設計語言（PDL）PDL（ProcedureDesignLanguage）也稱為結構英語或偽碼，是所有正文形式的過程設計工具的統稱。PDL經常表現為一種“混雜”的形式，允許自然語言（如英語）的詞匯與某種結構化程序設計語言（如Pascal、C、Ada等）的語法結構交織在一起第57頁,共82頁，2024年2月25日，星期天7.2.4過程設計語言（PDL）PDL應具有下述特點：1．關鍵字采用固定語法并支持結構化構件、數據說明機制和模塊化；2．處理部分采用自然語言描述；3．允許說明簡單（標量、數組等）和復雜（鏈表、樹等）的數據結構；4．子程序的定義與調用規則不受具體接口方式的影響。第58頁,共82頁，2024年2月25日，星期天7.2.4過程設計語言（PDL）考察一個PDL的原型，它可以建立在任意一個通用的結構化程序設計語言之上。基本成分包括：子程序定義、界面描述、數據說明、塊結構、分支結構、循環結構和I/O結構。數據說明的形式為：

TYPE<變量名>IS<限定詞1><限定詞2>其中：<變量名>——局部變量或全局變量；<限定詞1>——某個特定關鍵字（例如，SCALAR，ARRAY，LIST，STRING，STRUTURE等）；<限定詞2>——說明此處定義的變量在該過程或整個程序中應如何使用。第59頁,共82頁，2024年2月25日，星期天7.2.4過程設計語言（PDL）可進行抽象數據類型的定義，例如:TYPEtable_1ISINSTACEOFsymbol_table而symbol_table在另一處已定義如下：TYPEsymbol_tableISSTRUCTUREDEFINED第60頁,共82頁，2024年2月25日，星期天7.2.4過程設計語言（PDL）該PDL的塊結構描述一個過程元素，即一個塊內的所有語句將作為一個整體執行，形式為

BEGIN[<塊名>]<語句序列>END該PDL的分支結構有if-then-else和case兩種形式，分別為

IF<條件描述>THEN<塊結構或語句>ELSE<塊結構或語句>ENDIF第61頁,共82頁，2024年2月25日，星期天7.2.4過程設計語言（PDL）CASEOF<情況變量名>WHEN<第1種情況>SELECT<塊結構或語句>WHEN<第2種情況>SELECT<塊結構或語句>…WHEN<最后一種情況>SELECT<塊結構或語句>DEFAULT:<塊結構或語句>ENDCASE第62頁,共82頁，2024年2月25日，星期天7.2.4過程設計語言（PDL）循環結構包括三類，表達形式分別為：DOWHILE<條件描述><塊結構或語句>ENDWHILEREPEATUNTIL<條件描述><塊結構或語句>ENDREPEATDOFOR<循變>=<循變取值范圍,表達式或序列><塊結構或語句>ENDFOR第63頁,共82頁，2024年2月25日，星期天7.2.4過程設計語言（PDL）此PDL還提供了NEXT和EXIT兩種語句：

EXIT語句，退出本層循環；

NEXT語句強迫本次循環結束，新一輪循環開始。在該PDL中，子程序說明為：

PROCEDURE<子程序說明><屬性表>INTERFACE<參數表><塊結構或語句序列>END

其中屬性表指明該子程序的引用特性（比如，是INTERNAL還是EXTERNAL模式）和其他依賴于實現（即程序設計語言）的特性。第64頁,共82頁，2024年2月25日，星期天7.2.4過程設計語言（PDL）輸入/輸出說明部分常用的形式有

READ/WRITETO<設備><I/O表>

或

ASK<詢問>ANSWER<響應選擇項>

后一種形式多用于人機交互部分的設計。第65頁,共82頁，2024年2月25日，星期天7.3設計規格說明與評審軟件設計階段的輸出主要是設計規格說明書：第一節：描述與設計活動有關的各個方面，該節中許多信息取自系統規格說明書和系統定義階段產生的其他文檔。第二節：具體指明引用信息的出處。第三節：設計描述，是概要設計的產物，此時設計由信息驅動，即軟件總體結構主要受數據流程、數據結構的影響，需求分析時產生的DFD或其他某種形式的數據表示將在這一節中進一步精化，用于確定軟件結構。當信息流程確定后，界面亦可作為整個軟件的一部分進行描述。第66頁,共82頁，2024年2月25日，星期天7.3設計規格說明與評審第四、五兩節是概要設計向詳細設計過渡后形成的。第四節：模塊指軟件中可單獨編址的部件，如函數和過程，最初用自然語言描述它們的功能，隨后采用某種過程設計工具將這些自然語言描述轉換為結構化描述。第五節：主要描述數據組織結構，包括輔存的文件結構、全局數據（例如FORTRAN公共區）的賦值以及這些文件與全局數據的交叉訪問關系。第67頁,共82頁，2024年2月25日，星期天7.3設計規格說明與評審第六節：是與需求規格說明書的交叉訪問表，根據交叉訪問表可斷定設計是否滿足所有需求，這對于完成某個具體需求的模塊來說十分重要。第七節：是測試的初步計劃。一旦軟件結構和模塊間界面確定下來之后，即可制定模塊單元測試和聯調的計劃。某些場合，要求同時開發測試規格說明書與設計規格說明書，此時第七節可從設計規格說明書中刪去。第八節：將逐條說明各種限制和造成的影響。第九、十兩節：包括若干輔助數據，如從其他文檔中節選的算法描述、候選的過程、表格化數據和其他相關信息，這些信息是對設計的一種特殊注釋最后開發一基本操作規格說明或安裝手冊作為附錄。第68頁,共82頁，2024年2月25日，星期天設計規格說明書示例Ⅰ.作用范圍

A.系統目標

B.硬件、軟件和人機界面

C.主要的系統功能

D.外部數據庫定義

E.主要的設計約束和限制Ⅱ.文檔

A.現有的軟件文檔

B.系統文檔

C.賣主（硬件的和軟件的）的有關文檔

D.技術參考書第69頁,共82頁，2024年2月25日，星期天設計規格說明書示例Ⅲ.設計描述

A.數據描述

1.數據流復審

2.數據結構復審

B.導出的程序結構

C.結構之間的界面第70頁,共82頁，2024年2月25日，星期天設計規格說明書示例Ⅳ.模塊描述；針對每個模塊給出

A.處理過程陳述

B.接口描述

C.設計語言（或其他形式）描述

D.引用的模塊

E.數據組織

F.注釋第71頁,共82頁，2024年2月25日，星期天設計規格說明書示例Ⅴ.文件結構及全局數據

A.外部文件結構

1.邏輯結構

2.邏輯記錄描述

3.訪問方式

B.全局數據

C.文件與數據的交叉訪問表Ⅵ.需求交叉訪問矩陣第72頁,共82頁，2024年2月25日，星期天設計規格說明書示例Ⅶ.測試準備

A.測試指南

B.集成策略

C.特殊考慮Ⅷ.裝配

A.特殊的程序覆蓋要求

B.轉換方面的考慮Ⅸ.特別注釋Ⅹ.附錄第73頁,共82頁，2024年2月25日，星期天概要設計階段的文件主要是概要設計說明書，又稱為系統設計說明書。編寫本說明的目的，是說明對程序系統的設計考慮，包括程序系統的基本處理流程、程序系統的組織機構、功能分配、模塊劃分、接口設計、運行設計、數據結構設計和出錯處理設計等，為系統的詳細設計打下基礎。概要設計說明書是概要設計階段結束時提交的技術文檔。除了概要設計說明書之外，還有用戶手冊、測試計劃等文件。見下表第74頁,共82頁，2024年2月25日，星期天概要設計說明書1引言1．1目的1．2背景1．3定義1．4參考資料2概要設計

2．1需求規定

2．2運行規定

2．3基本設計原則與處理流程

2．4結構

2．5功能需求與程序關系

2．6人工處理過程

2．7未解決問題3接口設計

3．1用戶接口（用戶界面）

3．2內部接口（模塊間）

3．3外部接口（軟硬件間）4運行設計

4．1運行模塊組合

4．2運行控制

4．3運行時間5數據結構設計

5．1