系统功能设计.ppt

1、Chapter 4系統功能設計,4.1結構化設計與物件導向設計 4.2資料流程圖的符號與運用 4.3資料流程圖的內容 4.4結構圖 4.5處理規格,2,4.1 結構化設計與物件導向設計,4.1.1結構化設計 4.1.2物件導向方法 4.1.3兩種方法的分析與比較,3,4.1 結構化設計與物件導向設計,概述： 資訊系統的分析與設計大致上分成兩個派別： 結構化設計和物件導向設計。 兩者主要的差異是導因於系統開發所使用的程式語言不同。 第三代語言的效率很好，使用的人也很多，因此長久以來結構化設計的觀念和工具一直是系統分析與設計的主流。 但在物件導向語言出現後，由於加入了許多新的執行觀念，物件的執行方

2、式不再只能是序列式的，而是可以經由使用者來操作物件之間的互動和合作，以完成特定的功能流程。 而且物件導向的設計概念也需要物件導向的圖型化工具支援，因此終於促成了物件導向系統設計派別。,4,4.1.1 結構化設計(1/5),結構化方法的三種邏輯處理 企業的作業活動是一個步驟接著一個步驟的進行，系統分析師所用的圖形化工具也應具有一步接著一步的特性。 第三代語言的三種邏輯處理：循序性、選擇性、和重複性。,圖4-1 第三代語言的邏輯處理,5,4.1.1 結構化設計(2/5),循序性作業： 一行程式執行完，再執行下一行程式；或是當一支程式在執行過程中呼叫、並且進入下一層的程式後，必須要先等那支被呼叫地程

3、式執行完，才能返回原來的程式，也許再呼叫其他程式、或是繼續執行後續的指令。 選擇性作業： 是if-then-else的語法，必須依據判斷式中的條件，也就是if後面接著的條件是否符合，來決定要接著執行then後面的程式、或是else後面的程式 (但是兩者只會執行一個)。 重複性作業： 也就是迴圈，可以使用while loop或是for loop語法，而由判斷式中的條件來控制迴圈停止與否。,6,4.1.1 結構化設計(3/5),構化設計的三種不同角：功能、資料及使用者介面 以功能的角度看系統： 針對企業的某個 (些) 特定作業，以作業流程為導向，先將應用軟體分解成幾個功能，以找出要開發哪幾支程式，

4、並將上一層作業的程式所處理過後的資料傳給本層作業的程式來使用。 進行設計時主要是使用資料流程圖 (Data Flow Diagram, DFD) 來分解程式架構，同時清楚表示程式之間的資料傳遞。 結構化的主要概念還包含所謂的模組化 (Modulization)。當系統分析與設計團隊將系統切割成更小的單位，以利程式設計師分工合作來做程式的開發。 不論在哪個功能中，需要時就去呼叫該模組，如此便可以在多個功能中執行相同的工作，甚至以後的系統也可以再利用 (Reuse)。 以功能的角度看系統，有利於將系統的程式模組化。因為若是將相同活動合併開發，並萃取出獨立工作的模組，便能以模組的結構圖來架構系統，簡

5、化系統的設計。,7,4.1.1 結構化設計(4/5),以資料的角度看系統： 包括單一的資料與整體的資料庫。 在單一的資料部分，由於結構化的設計中包括了一個所謂的資料字典 (Data dictionary)。 資料字典的目的便是定義資料流程圖中的資料流，包括資料的名稱、資料型態、內容、限制、以及哪一個功能活動會使用到該資料等，因此只要有這個清楚的定義檔，就能避免資料被以錯誤的方式使用。 資料庫的設計，常用的圖形化工具是實體關係圖 (Entity-Relationship Diagram, ERD)，它可將資料庫的邏輯架構建立起來，以實體來對應資料庫中的表格、以屬性對應到表格中的欄位，並以欄位的資

6、料內容建立起表格之間的關聯關係，將實體之間的關係定義清楚。,8,4.1.1 結構化設計(5/5),以使用者介面角度看系統： 使用者需要的系統介面就是螢幕的畫面。 用來做系統的操作。友善的系統介面要有容易學、容易操作、符合既有操作習慣、美觀的色彩和設計 等特性，開發團隊中最好有專業的設計師，專注於人機介面的部分。 常是以使用者介面架構圖來表示介面的階層性。 此外也可以用雛型 (Prototype) 來捕捉使用者的需求，所謂的雛型系統，通常是以PC為工具，快速開發出系統大致的樣子，給使用者確認作業的流程和介面的操作。,9,4.1.2 物件導向方法(1/4),物件的特性： 概述： 物件可以想成是資料

7、庫設計中提到的實體 (Entity)，它和一般資料實體一樣，也有靜態的屬性 (Attribute)，用來定義物件的狀態 (Status)；但和實體不同地方是，物件具有動態的行為 (Behavior)、還有啟動物件的方法 (Method) 繼承 物件的集合稱為類別 (Class)，而類別之間則存在有繼承的觀念 繼承已做好的屬性和行為，再增加特殊的需求以成為另一個物件，便可以節省開發的力氣，並且方便管理和維護,10,4.1.2 物件導向方法(2/4),封裝 封裝的觀念是指將物件以不同層次的呼叫來使用，就好像將物件保護起來 。 最內層建立起物件本身的屬性資料，可將資料隱藏在物件之中。 向外的第二層是

8、物件本身的操作，可用來存取資料。 更外一層提供的是當呼叫物件的操作時，透過帶有訊息的資料來呼叫物件。 最外一層才是處理由其他物件所送來的服務要求。 物件內部的運作是被封裝起來的，因為每一個層面均能清楚的分開處理，所以使用時不需要考慮已封裝好的物件是如何運作的；如此一來，系統設計師便可以專注在物件之間的互動上，使系統設計工作更單純。,11,4.1.2 物件導向方法(3/4),UML 統一塑模語言 概述： 統一塑模語言提供了不同角度的圖形化工具，系統分析師可以依照不同的需求，採用不同的圖型化工具。 使用者需求的角度： UML提供使用案例 (Use case)，可以擷取使用者與資訊系統之間的互動情節

9、，也就是使用者希望將來資訊系統能做些什麼，常用在需求分析階段。 資料庫設計： 資料庫設計方面與結構化設計一樣，都是以實體關係圖來架構；當ERD圖設計完成之後，可以說物件的靜態屬性也建置完成。,12,4.1.2 物件導向方法(4/4),物件的靜態結構： 物件導向系統設計的主要目的是設計出各種物件，使得物件本身的操作、或是物件之間的互動操作，都可以滿足使用者對系統的需求。 物件的類別以類別圖 (Class diagram) 來架構，將各不同種類的物件設計出來，其中靜態的屬性要參照ERD圖的屬性，動態行為則要依靠動態的設計圖。 物件的動態結構： 物件的動態操作 (或是行為) 主要是為了能藉由物件本身

10、的操作、或是物件之間的互動操作，完成使用者對資訊系統的需求功能。 由互動圖可以捕捉物件的操作行為。 系統架構 系統的架構可以區分為軟體與硬體，UML提供了元件圖 (Component diagram) 來架構軟體的各種元件，包含執行檔、資料檔、起始設定檔、程式庫檔等； 另外也提供了部署圖 (Deployment diagram) 來架構硬體的建置，包含各種機器以及其網路的連結。,13,4.1.3 兩種方法的分析與比較,兩種方法的比較： 結構化設計和物件導向設計各有其不同的專注焦點，而根據兩者所採用之程式語言的不同特性，開發團隊可以有不同的選擇。 第三代程式語言在目前仍然是開發大型資訊系統的主要

11、工具，因為結構化觀念存在的時間較久，使用的人也比較多。 由於物件導向語言的盛行，其在開發小型系統的快速與便利性均使得物件導向設計日趨重要。 雖然結構化設計與物件導向系統設計有上述的種種不同，但兩者都必須在一定的開發方法論下循序開發，並不相互違背。,14,4.2 資料流程圖的符號與運用,4.2.1由上而下的觀念 4.2.2資料流程圖的符號與原則 4.2.3資料一致性,15,4.2資料流程圖的符號與運用,概述： 資料流程圖主要用來將系統做功能性的切割，由整體的系統看起，分析系統所在的環境，包括系統本身、企業內部的使用者實體、及其他相關系統的關係。 由上層圖(e.g., 系統環境圖)進入下一層圖，看

12、看系統內的主要功能，包括功能的內容、功能的操作者實體、資料的輸入和輸出。 接著將每一個功能做步驟的分析，同樣地包括作業內容、實體和資料的輸出和輸入，一直到分割出每一支要開發的程式。,16,4.2.1 由上到下的觀念(1/2),階層式圖示： 資料流程圖的基本架構是階層式的：越上層，所看到的範圍越廣；越下層，所看到的越是局部的細節。 從系統的最上層開始，先看到的是系統環境圖 (Context diagram)，在這裡把系統看成是一個大的作業處理，只專注在表示系統和其他系統或操作者實體之間的關係。 下一層是圖0，圖0非常重要，它只畫出主要功能。 接下來是圖1、圖2、圖3 等第二階的圖，它們分別將第一

13、階圖0裡面的某一個作業處理功能加以分解，以一步接一步更細的作業處理來完成。,17,4.2.1 由上到下的觀念(2/2),圖4-2 料流程圖的基本架構,18,4.2.2 資料流程圖的符號與原則(1/8),資料流程圖的符號：,19,4.2.2 資料流程圖的符號與原則(2/8),繪製原則： 作業處理一律採用數字編號，在系統環境圖中，以編號0代表整個資訊系統。 在圖0中，每個作業處理依照順序1、2、3等往下編號。 在圖1中，也就是作業處理1的細節圖，作業處理依照1.1、1.2、1.3等往下編號。 編號通常也代表執行順序，如在圖1.1中，作業處理依照1.1.1、1.1.2、1.1.3等往下編號，同時也解

14、釋了作業處理1.1的內容。 箭頭的意義： 箭頭有兩種意義，一個是資料流，另一個是表示操作的順序； 結構化的程式必須要有先後順序，當前一個處理操作完成，即進入下一個處理操作，兩個操作之間的箭頭不一定有資料的傳遞，但仍然有呼叫的意義。,20,4.2.2 資料流程圖的符號與原則(3/8),一層圖裡的作業處理個數： 圖形化工具的主要目的就是清楚地架構所要開發的功能，同一層圖內的作業處理個數如果太多，就會顯得太複雜，一般而言，最好不要超過7個。 資料流流向的相關限制： 作業一定要有資料流流入，才能處理並產生資料流；同樣地，資料流流入作業處理做處理操作後，也一定會有資料流流出。 資料儲存單位並不會做作業處

15、理，所以不能有資料流是由資料儲存單位流到資料儲存單位。 而實體之間也不會有資料流，因為實體不會直接存取資料。,21,4.2.2 資料流程圖的符號與原則(4/8),圖4-3 有問題的表示法,22,4.2.2 資料流程圖的符號與原則(5/8),處理只能有一個順序 資料流程圖不能處理判斷，必須要分不同的處理來做 如果有這樣的情形，必須回到上一層，將源頭的作業處理分成兩個,圖4-4 兩個執行緒,23,4.2.2 資料流程圖的符號與原則(6/8),箭頭不要交叉： 若是圖形內一大堆箭頭來往交叉，那麼不僅無法了解所要做的處理，更會令人不清楚資料流所要代表的是什麼； 通常將一個作業處理的輸入和輸出維持簡單的一

16、個資料流；,圖4-5 箭頭不要交叉,24,4.2.2 資料流程圖的符號與原則(7/7),由操作單位A到作業處理1.1的資料流可以合併成一個； 同樣地，作業處理1.1到作業處理1.2的箭頭也可以合併起來，以一個資料流來取代； 將作業處理1.3和資料檔C換一下位置，即可避免箭頭交叉； 作業處理1.3需要儲存到資料檔的資料若合併成一個資料流，看起來比較清爽，也容易理解作業的順序、和每個作業處理之間資料流的輸入和輸出。 加上說明文字： 有圖就要有說明，每個圖都需要說明其內容和意義。,25,4.2.3 資料一致性(1/2),概述： 資料流在上一層圖裡可以是好多個資料項目的集合，等到了下一層圖再分成好幾項

17、的資料流，做分步驟的處理。 資料流程圖的基本精神就是分層處理，例如下圖中的例子，左側為在最上層圖0中的部分圖，當中的作業處理2可以再往下一層分解作業流程。 右側的圖2即是處理的分解圖，將作業處理2再分成三個步驟，分別是2.1、2.2和2.3，由作業流程2.1開始，依序處理完作業流程2.2及2.3之後才算完成作業2。,26,4.2.3 資料一致性(2/2),圖4-6 資料一致性圖示,27,4.3 資料流程圖的內容,4.3.1系統環境圖 4.3.2圖0 4.3.3較低階層圖 4.3.4資料字典,28,4.3資料流程圖的內容 (1/2),概述： 資料流程圖是由多個圖組成的，包含系統環境圖、圖0、圖1

18、、圖2、圖3、圖4、圖1-1、圖1-2、圖1-3、 圖2-1、圖2-2、圖2-3。 越高層的圖看到的越整體、越低層的圖則看得越細節。 一直到每個處理都已經可以用一支程式來完成，那才算是最底層的圖，可以停止往下畫了。,29,4.3資料流程圖的內容 (2/2),圖4-7 資料流程圖架構,30,4.3.1 系統環境圖(1/2),說明： 系統環境圖用來表示資訊系統和環境之間的關係，可以作為資料流程圖的第0層，就是最上一層，也可以說是第0階。 系統環境圖的觀點是從外部看系統整體，目的是定義系統和外界的關係。 若以作業處理來代表整個資訊系統，其編號是0；另以實體表示操作系統的使用者 (可以是單位、人，或表

19、示其他的系統)，並以資料流來連接。,31,4.3.1 系統環境圖(2/2),圖4-8 上紅實業採購系統之系統環境圖,採購處,高階主管,倉儲系統,品管單位,會計單位,0,32,4.3.2 圖0 (1/3),說明： 圖0是資料流程圖的第一階，將系統的主要功能畫在一張圖上。 圖0把系統環境圖做進一步的分解，切割成幾個重要的功能，以作業處理來表示。 各功能之間，沒有資料流或作業的關聯： 功能可以想成是在一個特定的時間做一件事情，圖0代表系統要開發幾個功能，也就是系統能協助使用者做幾件事情，且每一件事情都是分開獨立的。 在圖0裡的任何兩個作業處理，都不能存在有箭頭 (資料流)。,33,4.3.2 圖0

20、(2/3),每個實體和每個功能之間的資料流要合併成一個： 每一個功能可能需要好幾個步驟才能完成，但是在圖0並不會表示出功能內的步驟。 在圖0中，每個功能的輸入和輸出必須合併成一個輸入或是輸出的資料流，到下一層的圖才分解開來。 也就是圖上僅表示使用者在操作這個作業處理時是否需要輸入資料、或是系統是否會給使用者回覆輸出，這樣子的圖看起來才乾淨又清楚。 除了作業處理之外，其他的符號都可以重複： 為了不讓箭頭交叉，除了作業處理之外，其他的符號像實體、儲存單位或是資料流，都是可以重複出現的。 但是要注意名稱不可以改變，名稱一樣就表示是同一個東西。,34,4.3.2 圖0 (3/3),圖4-9 上紅實業採

21、購系統圖0,35,4.3.3 較低階層圖(1/3),對應與分解： 較低階的資料流程圖為較高階的分解圖，其目的是把上一階圖內的各個作業分解為細部步驟，並且將較詳細的資料流定義出來。 既然較低階的資料流程圖是由上一層中的作業處理所分解出來的，所以彼此之間一定有對應關係，不論是資料流，或是作業流程的上、下步驟皆應如此。 針對同一個作業處理，亦必須考慮其上層和下層之間資料的一致性。,36,4.3.3 較低階層圖(2/3),圖4-10 上紅實業請採購系統圖1,37,4.3.3 較低階層圖(3/3),圖4-11 上紅實業採購系統圖2,38,4.3.4 資料字典,概述： 資料字典是用來說明及定義資料流程圖中

22、的資料，除了實體之外，包含每一個在資料流程圖中的作業處理、檔案、資料流以及資料項目的內容，均以一定的格式來建立。 通常會用表格的方式，依照編號順序將上述的內容逐一填入，建置起完整的資料字典，以配合資料流程圖的使用，提供使用者查詢。 資料流是由哪些資料項目組成，也要在資料字典中定義清楚。 舉例說明如下：,39,4.3.4.1 作業處理(1/2),40,4.3.4.1 作業處理(2/2),41,4.3.4.2 檔案,42,4.3.4.3 資料流(1/2),43,4.3.4.3 資料流(2/2),44,4.3.4.4 資料項目(1/2),45,4.3.4.4 資料項目(2/2),46,4.4結構圖,

23、4.4.1結構圖的意義與符號定義 4.4.2模組化與評估模組的標準 4.4.3結構圖的必要性,47,4.4結構圖,概述： 資料流程圖畫完之後不能直接拿來寫程式，還需要一個步驟，就是將資料流程圖轉成結構圖 (Structure chart)。 其主要目的是以模組的角度，將相同功能的處理合併，並且將結構圖中的模組以結構化英文來表示。 這樣才能交給程式設計師開發程式。原因是，在設計資料流程圖時，是以功能流程為導向的。,48,4.4.1 結構圖的意義與符號定義(1/5),結構圖的意義： 資料流程圖是以系統個別的功能為角度來設計，各個功能之間並不知道彼此在做什麼。 所以需要有另一種圖，來整理出資料流程圖

24、中有哪些功能是重複的，或者說哪些程式是可以再利用的。,49,4.4.1 結構圖的意義與符號定義(2/5),圖4-12 結構圖,50,4.4.1 結構圖的意義與符號定義(3/5),圖4-12說明： 圖4-12的結構圖主要是將資訊系統以模組來架構，再將每個模組按照動作來做分割。 例如上圖中的系統就是先切割成三大模組，其中模組A又分成兩個動作，且執行時一定是由左執行到右，所以是動作a先做，才做動作b； 再往下看，動作a又切割成動作a1和動作a2，同樣地，要先做動作a1、再做動作a2。 而資料的流向則是先由動作a1取得資料a，並且在動作a完成之後將資料a傳遞給動作b。 至於動作b則是先做動作a2、再做

25、動作b1，等動作b1完成之後，會標示一個旗標b，例如將旗標b的值由0改變成1，以供後續的動作檢查狀態之用。,51,4.4.1 結構圖的意義與符號定義(4/5),其他說明： 結構圖和資料流程圖並不呈一對一的對應，而是將資料流程圖中有重複動作的部分合併起來，只開發一個共用模組來供相同的動作使用。 結構圖是將資料流程圖加以整理、設計，以找出真正需要開發的程式。 模組圖當然也可以只用一張來畫整體架構圖，另外很多張則都是畫各個模組內部的模組圖，將每個模組內的較細部狀況畫出來。,52,4.4.1 結構圖的意義與符號定義(5/5),圖4-13 登錄結構圖,53,4.4.2 模組化與評估模組的標準(1/8),

26、概述： 模組化指的是以相關的程式為單位，將系統的所有程式切割成一組一組。 定義出每一組的輸入、該組程式所要做的事情、以及執行後的輸出，像這樣切割出來的每一組程式便稱為一個模組。 模組最大的好處是可以再利用，如果不以模組來架構程式，很可能對於每一個功能的作業，程式設計師都必須以一支大程式來解決。 評估模組有兩個著名的標準，一個是內聚力 (Cohesion)，另一個是偶合力 (Coupling)。,54,4.4.2 模組化與評估模組的標準(2/8),內聚力： 概述： 內聚力是指模組內部的每個部分，是不是應該放在同一個模組中。 切割模組當然是內聚力越高越好，內聚力有好幾種，依其影響力大小，大致排列如

27、下。 功能內聚力 (Functional cohesion) 指一個模組只做一件事情，比如像是檢查帳號及密碼、計算平均值、新增一筆訂單資料到資料庫去等，這些模組的內聚力很高。 順序內聚力 (Sequential cohesion) 順序的內聚力指的是有多個動作在這個模組中，但是這些動作之間彼此的關係很緊密，一個動作做完之後的產出，即是下一個動作的輸入 比如用一個程式模組來找出最大值：第一個動作是將一群資料輸入，接著將這一群資料一一來做比較，找出其中最大的值，最後再把結果輸出；這樣子的模組稱為有順序內聚力的模組。,55,4.4.2 模組化與評估模組的標準(3/8),溝通內聚力 (Communic

28、ation cohesion) 指這個模組內有多個作業使用一樣的輸入資料，但是這些作業在執行上並沒有順序性；可以看得出來，這樣的內聚力要比順序內聚力的緊密程度差一點。 像是查詢客戶的付款方式、查詢客戶的聯絡人、查詢客戶的付款折扣，這三者用到的資料都是客戶資料，但是無論哪一個值先查都可以，若將這三個作業放在一起成為一個模組，則稱這個模組具有使用相同資料的溝通內聚力。 程序內聚力 (Procedural cohesion) 在這個模組內的作業並不共享資料，但卻必須要按照一定的順序來執行，而且所完成的事情在真實的世界裡其實並沒有太多的意義。 它們可能只是在執行系統的時候，一些要完成的事情，所以把這些

29、作業放在一起，以便確定這些作業可以按照一定的順序做完。 比如說，修改一筆訂單資料、記錄使用者帳號及時間、標示修改符號，將這幾個動作放在同一個模組，以確定其執行的程序性，即稱這個模組具有程序內聚力,56,4.4.2 模組化與評估模組的標準(4/8),時間性內聚力 (Temporal cohesion) 如果一個模組內的幾個作業，是因為需要同時被作業而放在一起，這樣子的模組就是時間性的內聚力。 這項內聚力和執行的時間相關，比如像是將設定一個系統起始值的幾個動作放在同一個模組，則這個模組便具有時間的內聚力。 邏輯內聚力 (Logical cohesion) 當具有邏輯上相關的作業放在同一個模組裡，即

30、稱此模組具有邏輯內聚力。 比如像是輸出模組，便可包括錯誤資訊、報表、和備份資料，雖然都是輸出，但它們只是邏輯上均從資訊系統輸出到周邊設備去，但是周邊設備卻不一樣、輸出內容也沒有關聯；這樣設計並不是好的做法。 偶然內聚力 (Coincidental cohesion) 模組內的作業只是偶然放在一起，沒有任何的原因，這樣的模組稱為具有偶然內聚力的模組。,57,4.4.2 模組化與評估模組的標準(5/8),偶合力： 概說： 偶合力是指模組和模組之間的關聯，理論上應該越小越好。 如果一個模組會和別的模組多所牽連，就表示此模組是和這次開發的系統高度相關，那麼再利用的價值可能會較低。 偶合力可分為以下幾種

31、： 無直接偶合力 (No direct coupling) 模組之間沒有關聯，無直接的偶合力存在。 資料偶合力 (Data coupling) 兩個模組之間有一些簡單的資料傳遞。 我們以審核客戶信用額度和客戶訂單這兩個模組為例：由於客戶訂單模組必須根據客戶信用額度來作業，因此審核客戶信用額度的模組必須將客戶信用額度傳送給客戶訂單模組，所以這兩個模組之間存在著因資料傳遞而構成的關聯。,58,4.4.2 模組化與評估模組的標準(6/8),郵戳偶合力 (Stamp coupling) 指兩個模組之間有資料結構上的相關連，也就是說兩個模組會去修改或是新增同一個表格、或是表格內的幾個欄位。 比如訂單的資

32、料表格，就有訂單總價計算和訂單定價這兩個模組會分別去決定訂單資料中的總價和定價欄位，這兩個模組的關連性是透過訂單資料表格中的幾個特定欄位所形成，我們稱兩個模組間具有郵戳偶合力，或者稱為資料結構偶合力。 控制偶合力 (Control coupling) 當兩個模組之間所傳遞的是旗標，即一個模組以旗標來控制另一個模組的作業，這和模組內部的執行邏輯有關。 假使一個模組改變了旗標之後，會影響另一個模組的運作，以列印庫存報表和盤點這兩個模組為例，在列印庫存報表之前必須先檢查盤點模組的進度，確定某一個產品完成盤點後才能列印。,59,4.4.2 模組化與評估模組的標準(7/8),外部偶合力 (Outside

33、 coupling) 假設兩個模組共用外部定義的變數，當外部變數改變時，會影響到這兩個模組，則這兩個模組之間稱為有外部偶合力。 比如，定價模組內的產品價格，會同時影響到訂單總計模組和客戶信用餘額模組，所以訂單總計和客戶信用餘額這兩個模組便同時受到產品價格這個外部變數的影響，這種情況可以稱為有外部偶合力。 共同偶合力 (Common coupling) 共同偶合力指的是兩個模組使用相同的資料區，而且都可以讀、寫資料區內的資料。 比如，盤點模組和庫存模組都可以更新庫存量，這兩個模組在寫入相同模組時，必須要做良好的控制，否則會有資料錯誤的情況，若兩個模組擁有對相同變數的寫入權，則稱這兩個模組之間有共

34、同偶合力。,60,4.4.2 模組化與評估模組的標準(8/8),內容偶合力 (Content coupling) 兩個模組在執行的內容上互相相關，像是有些程式語言中的goto的指令，會使得執行緒在一個模組執行到一半時忽然跳到另一個模組，這時這兩個模組便具有內容偶合力。 這樣是比較不好的設計，當很多goto在一個模組中的時候，執行的順序就已經很混亂了，如果再加上兩個、三個模組，並且容許在內容的執行上跳來跳去，那一定更難以管理，而且違背了模組化的基本概念。,61,4.4.3 結構圖的必要性,說明： 這當然是見仁見智的事情，完全由系統設計者依專案的情況來決定。 但由於程式語言的不斷進化，許多指令本身

35、已經能完成複雜的動作，而且很多開發工具又提供了強大的函式庫，因此原本需要寫兩三支程式才能做得完的事情，現在可能只要一支簡單的程式就可解決。 需要撰寫的程式變少了，所以結構圖的角色已經沒有像以前那麼的重要。,62,4.5處理規格,4.5.1處理規格的表達 4.5.2虛擬碼中常見的保留字 4.5.3虛擬碼應用保留字的實例 4.5.4巢狀指令,63,4.5.1 處理規格的表達(1/4),概述： 撰寫處理規格是系統設計師的主要工作之一，其目的在於說明所要開發的程式或物件的詳細內容。 之前所討論的系統設計方法，都只是用圖形將系統要開發什麼東西給畫出來，但是並沒有正式設計到程式的邏輯解法。 所謂邏輯解法也就是程式的演算法，或可說是執行流程，亦即如何一步一步的將問題解決；處理規格通常以虛擬碼 (Pseudo-code) 來表達。 虛擬碼雖不是真正的程式碼，但也已相去不遠。,64,4.5.1 程式規格的表達(2/4),程式設計師只要拿到虛擬碼，就能依照所開立的規格寫出對應的程式，而不需要知道其他的部分。 在開發系統的過程中，需要不同的專業人員一起團隊合作，當這個系統很大、很複雜、或是開發團隊成員需要同時參與不同的專案時，專業的分工就非常重要，每個人