系统功能设计解读

使用者需求的角度：


資料庫設計：

11
4.1.2 物件導向方法(4/4)

物件的靜態結構：

物件導向系統設計的主要目的是設計出各種物件，使得物件本身的操作、或 是物件之間的互動操作，都可以滿足使用者對系統的需求。 物件的類別以類別圖 (Class diagram) 來架構，將各不同種類的物件設計出 來，其中靜態的屬性要參照ERD圖的屬性，動態行為則要依靠動態的設計圖。 物件的動態操作 (或是行為) 主要是為了能藉由物件本身的操作、或是物件之 間的互動操作，完成使用者對資訊系統的需求功能。 由互動圖可以捕捉物件的操作行為。 系統的架構可以區分為軟體與硬體，UML提供了元件圖 (Component diagram) 來架構軟體的各種元件，包含執行檔、資料檔、起始設定檔、程式 庫檔等； 另外也提供了部署圖 (Deployment diagram) 來架構硬體的建置，包含各種 機器以及其網路的連結。

加上說明文字：

有圖就要有說明，每個圖都需要說明其內容和意義。
24
4.2.3 資料一致性(1/2)

概述：



資料流在上一層圖裡可以是好多個資料項目的集合，等到了下一 層圖再分成好幾項的資料流，做分步驟的處理。 資料流程圖的基本精神就是分層處理，例如下圖中的例子，左側 為在最上層圖0中的部分圖，當中的作業處理2可以再往下一層分 解作業流程。 右側的圖2即是處理的分解圖，將作業處理2再分成三個步驟，分 別是2.1、2.2和2.3，由作業流程2.1開始，依序處理完作業流程2.2 及2.3之後才算完成作業2。

箭頭有兩種意義，一個是資料流，另一個是表示操作的順序； 結構化的程式必須要有先後順序，當前一個處理操作完成，即進入下一個處理 操作，兩個操作之間的箭頭不一定有資料的傳遞，但仍然有呼叫的意義。
19
4.2.2 資料流程圖的符號與原則(3/8)

一層圖裡的作業處理個數：

圖形化工具的主要目的就是清楚地架構所要開發的功能，同一層圖內的作業處 理個數如果太多，就會顯得太複雜，一般而言，最好不要超過7個。 作業一定要有資料流流入，才能處理並產生資料流；同樣地，資料流流入作業 處理做處理操作後，也一定會有資料流流出。 資料儲存單位並不會做作業處理，所以不能有資料流是由資料儲存單位流到資 料儲存單位。 而實體之間也不會有資料流，因為實體不會直接存取資料。
8
4.1.2 物件導向方法(1/4)

物件的特性：

概述：

物件可以想成是資料庫設計中提到的實體 (Entity)，它和一般資料實體一樣，也 有靜態的屬性 (Attribute)，用來定義物件的狀態 (Status)；但和實體不同地方是， 物件具有動態的行為 (Behavior)、還有啟動物件的方法 (Method) 物件的集合稱為類別 (Class)，而類別之間則存在有繼承的觀念 繼承已做好的屬性和行為，再增加特殊的需求以成為另一個物件，便可以節省 開發的力氣，並且方便管理和維護
6
4.1.1 結構化設計(4/5)

以資料的角度看系統：

包括單一的資料與整體的資料庫。 在單一的資料部分，由於結構化的設計中包括了一個所謂的資料字典 (Data dictionary)。

資料字典的目的便是定義資料流程圖中的資料流，包括資料的名稱、資料型態、內容、 限制、以及哪一個功能活動會使用到該資料等，因此只要有這個清楚的定義檔，就能避 免資料被以錯誤的方式使用。
15
4.2.1 由上到下的觀念(1/2)

階層式圖示：




資料流程圖的基本架構是階層式的：越上層，所看到的範圍越廣； 越下層，所看到的越是局部的細節。 從系統的最上層開始，先看到的是系統環境圖 (Context diagram)， 在這裡把系統看成是一個大的作業處理，只專注在表示系統和其 他系統或操作者實體之間的關係。 下一層是圖0，圖0非常重要，它只畫出主要功能。 接下來是圖1、圖2、圖3… 等第二階的圖，它們分別將第一階圖0 裡面的某一個作業處理功能加以分解，以一步接一步更細的作業 處理來完成。

由操作單位A到作業處理1.1的資料流可以合併成一個； 同樣地，作業處理1.1到作業處理1.2的箭頭也可以合併起來，以一個資料流來 取代； 將作業處理1.3和資料檔C換一下位置，即可避免箭頭交叉； 作業處理1.3需要儲存到資料檔的資料若合併成一個資料流，看起來比較清爽， 也容易理解作業的順序、和每個作業處理之間資料流的輸入和輸出。

以使用者介面角度看系統：


使用者需要的系統介面就是螢幕的畫面。 用來做系統的操作。友善的系統介面要有容易學、容易操作、符合既有操作習 慣、美觀的色彩和設計… 等特性，開發團隊中最好有專業的設計師，專注於人 機介面的部分。 常是以使用者介面架構圖來表示介面的階層性。 此外也可以用雛型 (Prototype) 來捕捉使用者的需求，所謂的雛型系統，通常是 以PC為工具，快速開發出系統大致的樣子，給使用者確認作業的流程和介面的 操作。

繼承

9
4.1.2 物件導向方法(2/4)

封裝

封裝的觀念是指將物件以不同層次的呼叫來使用，就好像將物件保護起來 。 最內層建立起物件本身的屬性資料，可將資料隱藏在物件之中。 向外的第二層是物件本身的操作，可用來存取資料。 更外一層提供的是當呼叫物件的操作時，透過帶有訊息的資料來呼叫物件。 最外一層才是處理由其他物件所送來的服務要求。 物件內部的運作是被封裝起來的，因為每一個層面均能清楚的分開處理，所以 使用時不需要考慮已封裝好的物件是如何運作的；如此一來，系統設計師便可 以專注在物件之間的互動上，使系統設計工作更單純。
16
4.2.1 由上到下的觀念(2/2)
圖4-2 料流程圖的基本架構
17
4.2.2 資料流程圖的符號與原則(1/8)
資料流程圖的符號：
18
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等往下編號，同時也解釋了作業處理1.1的內容。 箭頭的意義：
Chapter 4 系統功能設計
4.1 4.2 4.3 4.4 4.5 結構化設計與物件導向設計 資料流程圖的符號與運用 資料流程圖的內容 結構圖 處理規格
4.1 結構化設計與物件導向設計

4.1.1 4.1.2 4.1.3
結構化設計 物件導向方法 兩種方法的分析與比較
2
4.1 結構化設計與物件導向設計

一行程式執行完，再執行下一行程式；或是當一支程式在執行過程中呼叫、並 且進入下一層的程式後，必須要先等那支被呼叫地程式執行完，才能返回原來 的程式，也許再呼叫其他程式、或是繼續執行後續的指令。 是if-then-else的語法，必須依據判斷式中的條件，也就是if後面接著的條件是否 符合，來決定要接著執行then後面的程式、或是else後面的程式 (但是兩者只會 執行一個)。 也就是迴圈，可以使用while loop或是for loop語法，而由判斷式中的條件來控 制迴圈停止與否。

概述：

資訊系統的分析與設計大致上分成兩個派別：

結構化設計和物件導向設計。 兩者主要的差異是導因於系統開發所使用的程式語言不同。


第三代語言的效率很好，使用的人也很多，因此長久以來結構化 設計的觀念和工具一直是系統分析與設計的主流。 但在物件導向語言出現後，由於加入了許多新的執行觀念，物件 的執行方式不再只能是序列式的，而是可以經由使用者來操作物 件之間的互動和合作，以完成特定的功能流程。 而且物件導向的設計概念也需要物件導向的圖型化工具支援，因 此終於促成了物件導向系統設計派別。
10
4.1.2 物件導向方法(3/4)

UML － 統一塑模語言

概述：

統一塑模語言提供了不同角度的圖形化工具，系統分析師可以依照不同的需 求，採用不同的圖型化工具。 UML提供使用案例 (Use case)，可以擷取使用者與資訊系統之間的互動情節， 也就是使用者希望將來資訊系統能做些什麼，常用在需求分析階段。 資料庫設計方面與結構化設計一樣，都是以實體關係圖來架構；當ERD圖設 計完成之後，可以說物件的靜態屬性也建置完成。
3
4.1.1 結構化設計(1/5)

結構化方法的三種邏輯處理


企業的作業活動是一個步驟接著一個步驟的進行，系統分析師所 用的圖形化工具也應具有一步接著一步的特性。 第三代語言的三種邏輯處理：循序性、選擇性、和重複性。
圖4-1 第三代語言的邏輯處理
4
4.1.1 結構化設計(2/5)

循序性作業：
13
4.2 資料流程圖的符號與運用

4.2.1 4.2.2 4.2.3
由上而下的觀念 資料流程圖的符號與原則 資料一致性
14
4.2 資料流程圖的符號與運用

概述：


資料流程圖主要用來將系統做功能性的切割，由整體的系統看起， 分析系統所在的環境，包括系統本身、企業內部的使用者實體、 及其他相關系統的關係。 由上層圖(e.g., 系統環境圖)進入下一層圖，看看系統內的主要功能， 包括功能的內容、功能的操作者實體、資料的輸入和輸出。 接著將每一個功能做步驟的分析，同樣地包括作業內容、實體和 資料的輸出和輸入，一直到分割出每一支要開發的程式。

選擇性作業：


重複性作業：
ຫໍສະໝຸດ Baidu
5
4.1.1 結構化設計(3/5)

構化設計的三種不同角：功能、資料及使用者介面

以功能的角度看系統：


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

資料庫的設計，常用的圖形化工具是實體關係圖 (Entity-Relationship Diagram, ERD)，它可將資料庫的邏輯架構建立起來，以實體來對應資料庫中的表格、以 屬性對應到表格中的欄位，並以欄位的資料內容建立起表格之間的關聯關係， 將實體之間的關係定義清楚。
7
4.1.1 結構化設計(5/5)
12

物件的動態結構：


系統架構


4.1.3 兩種方法的分析與比較

兩種方法的比較：

結構化設計和物件導向設計各有其不同的專注焦點，而根據兩者 所採用之程式語言的不同特性，開發團隊可以有不同的選擇。 第三代程式語言在目前仍然是開發大型資訊系統的主要工具，因 為結構化觀念存在的時間較久，使用的人也比較多。 由於物件導向語言的盛行，其在開發小型系統的快速與便利性均 使得物件導向設計日趨重要。 雖然結構化設計與物件導向系統設計有上述的種種不同，但兩者 都必須在一定的開發方法論下循序開發，並不相互違背。

資料流流向的相關限制：



20
4.2.2 資料流程圖的符號與原則(4/8)
圖4-3 有問題的表示法
21
4.2.2 資料流程圖的符號與原則(5/8)

處理只能有一個順序

資料流程圖不能處理判斷，必須要分不同的處理來做 如果有這樣的情形，必須回到上一層，將源頭的作業處理分成兩個
圖4-4 兩個執行緒
22
4.2.2 資料流程圖的符號與原則(6/8)

箭頭不要交叉：


若是圖形內一大堆箭頭來往交叉，那麼不僅無法了解所要做的處理，更會令人 不清楚資料流所要代表的是什麼； 通常將一個作業處理的輸入和輸出維持簡單的一個資料流；
圖4-5 箭頭不要交叉
23
4.2.2 資料流程圖的符號與原則(7/7)