11

　

第 8 章 建構分析模型　

22

建構分析模型

在技術層次上，軟體工程由一系列的軟體塑模任務開始，以引導需求的規格和各式各樣軟體設計表示的建構。 分析模型 (analysis model) 實際上是一組模型，它是系統第一項技術的呈現。

33

分析塑模方法的流程 Tom DeMarco 在分析塑模方法的書籍中，描述此種方法的流程： 回顧已知問題和分析階段的失敗，建議我們需要附加下列項目到分析階段目標：

• 分析的產品必須是高度可維護的。這特別地應用於目標文件。

• 規模的問題必須使用有效的分割方法處理。• 無論何時，若可能則必須使用圖形。• 我們必須區別邏輯的與實際的間的顧慮…。

44

需求分析

需求分析 (requirements analysis) 的結果

軟體作業特性的規格 指出與其他系統元素的軟體介面 建立軟體所必須符合的侷限

55

需求分析的活動 需求分析允許軟體工程師或塑模者細化在較早需求工程任務的期間所建立的基本需求，和建立描述使用者情境、功能的活動、問題類別與它們的關係、系統與類別行為、和作為被轉換的資料流的模型。

需求分析提供軟體設計者可以被轉換成架構、介面和元件層級設計的訊息、功能和行為的表示。

一旦軟體被建造時，分析模型與需求規格提供開發者與顧客評估品質的方法。

66

分析塑模的主要聚焦 整個分析塑模，軟體工程師主要聚焦於什麼 (what) ，而不

是如何 (how) 。 系統操作什麼物件、系統必須要執行什麼功能、系統呈現什麼行為、定義什麼介面、應用什麼侷限因素？

在此階段需求的完整規格也許是不可能的。 顧客或許不確定什麼是必要的。 開發者或許也不確定什麼樣的特定方式將可適當地完成其功能與性能。

這些現實緩和對有利於需求分析與塑模的反覆方式的支持。

分析師應該將已知的塑模，並使用此模型作為軟體增量設計的基礎。

77

分析模型總體目標與哲學

分析模型必須達成三個主要的目標： 描述顧客的需求 建立軟體設計的創造基礎 一旦軟體建造時定義一組可被確認的需求。

分析模型橋接系統層級間的縫隙，藉由軟體、硬體、資料、人和其他的系統元素與描述軟體的應用架構、使用者介面及元件層級結構的軟體設計整體系統功能性。

88

分析模型於系統描述與設計模型間作為橋樑

99

分析的基本法則 ( 一 )

Arlow 與 Neustadt 建議一些在創造分析模型時應該遵循的有價值的經驗法則： 模型應該聚焦在問題或商務領域中可見的需求。

• 抽象化的層級應該相對地很高。• 「不要陷入細節而動彈不得」，試著解釋系統將如何工作。

分析模型的每個元素應該增加整體軟體需求的理解，並提供系統資訊領域、功能和行為的洞察力。

直到設計前延遲考慮基礎建設與其他非功能性的模型。

1010

分析的基本法則 ( 二 )

整個系統的耦合最少化。• 很重要的是表示類別與功能間的關係。• 如果「互相連結 (interconnectedness)」的層級非常高，應該努力將它降低。

確定分析模型對所有的利益共享者提供價值。• 每批顧客都有他自己對模型的使用。

儘量維持模型簡單，若無法提供新的資訊，不要增加額外的圖表。• 當簡單的列表可以表示時，不要使用完整的記號格式。

1111

領域分析 分析模式時常在特定的商務領域中，跨越許多應用程式而一再地發生。 如果這些模式採用讓軟體工程師或分析師得以確認與重複使用它們的方法來定義與分類，則分析模型的創造可以被加速。• 應用可重複使用的設計模式與可執行的軟體元件將得以戲劇性的成長。

• 這將改善上市的時間，並降低開發費用。 如何在最初就辨認出分析模式？誰定義它們、分類它們，並準備好在接下來的專案中使用它們？ 這些問題的答案有賴於領域分析。

1212

領域分析的描述

Firesmith 以下列的方式描述領域分析： 軟體領域分析是從特定的應用領域中的識別、分析和共同需求的規格，典型的在多重專案應用領域中的重複使用於… [ 物件導向的領域分析是 ]辨識、分析和共同的規格，在特定應用領域中的重複使用能力，根據共通的物件、類別、次要配件 (subassemblies) 和框架。

1313

領域分析的目標

領域分析的目標 以發現或創造哪些分析類別及 / 或共同的功能，和廣泛可應用的性能，因此它們可以重複使用。

在某些方式中，領域分析師的角色類似於在大量的製造環境中技師長的角色。

技師的工作是設計與建造讓許多人做類似但不一定相同的工作所使用的工具。

領域分析師的角色是發現與定義許多工作於類似、但不一定相同的應用程式的人所使用的可重複分析模式、分析類別和相關的資訊。

1414

領域分析的輸入與輸出

1515

分析模型建立方法

分析模型的一個觀點稱為結構化分析 (structured analysis) ，它考慮資料與轉換資料成為個別實體的流程。

資料物件以定義它們的屬性與關係的方法進行模型化。

操縱資料物件的流程以顯示它們如何轉換流經系統的資料成為資料物件的方法被模型化。

第二種被稱為物件導向分析 (object-oriented analysis)的方式是分析塑模，其聚焦於它們類別的定義，和與其他協同合作以影響顧客需求的方法。

1616

最佳的分析模型 本書中的分析模型建議結合此兩種方式的性能。 軟體團隊通常只選擇一種方式並排除其他的所有的表示方式。

問題不是那一個最好，而是什麼樣表示的組合可以提供利益共享者最好的軟體需求模型，和對軟體設計最有效的橋接。

1717

分析模型的元素

1818

資料塑模概念

分析塑模經常從資料塑模開始 軟體工程師或分析師定義在系統中所處理的所有資料物件、資料物件間的關係、和其他與資料物件適當關係訊息間的資訊。

1919

資料物件

資料物件 (data object)幾乎是任何必須為軟體所瞭解的合成訊息的表示。

合成資訊 (composite information)意謂有一些不同的性質或屬性的事。「寬度 (width) 」 (單一值 ) 將不是一個有效的資料物件，但維度 (dimensions)( 結合高度、寬度和深度 ) 將可定義為一個物件。

資料物件只含括資料。 在資料物件中沒有參照可操作資料的動作。

2020

資料屬性

資料屬性 (data attributes) 定義資料物件的性質，並且具有三種不同特性中的一種。它們可用來：

命名資料物件的個例 (instance) 描述個例 作為參照到另一個表格中的個例

對給定資料物件適當的屬性組是經過對問題環境的瞭解而決定的。

2121

關係

資料物件以不同的方式彼此連結。 考慮二種資料物件：人 (person) 和汽車 (car) 。 這些物件能使用簡單的記號表示。 因為兩個物件是相關的，所以在人與汽車之間建立連接。

2222

資料物件間的關係

2323

物件導向分析

任何物件導向分析的討論必須要針對物件導向 (object-oriented) 這個術語開始。

屬性 類別 物件 操作

2424

物件導向分析的任務

物件導向分析 (OOA) 的意圖是定義所有與問題有關而需要解決的類別。為達成此目標，許多的任務必定要發生：

基本的使用者需求必須要在顧客與軟體工程師之間溝通。

類別一定要確認。 (即屬性與方法被定義 ) 定義類別的階層。 物件對物件的關係 ( 物件連結 ) 應該被呈現。 物件行為必須被塑模。 任務 1 至 5 可反覆地再應用，直到模型完成。

2525

類別為導向的模型

OOA依賴對 OO觀念的理解，建立以類別為導向的模型 除了傳統的輸入 - 處理 -輸出模型。 及從階層的資訊結構中所獲得的專屬模型檢查問題以外。

2626

情境為基礎的塑模

以電腦為基礎的系統或產品成功的衡量有許多方式，但使用者的滿意度應該放列表的最高項目。

如果軟體工程師瞭解終端使用者想要如何與某個系統互動，則軟體團隊將會更恰當地特性化需求，並且建立有意義的分析與設計模型。

以 UML 的分析塑模由使用案例、活動圖和泳道圖的情境創造開始。

2727

撰寫使用案例

使用案例可以掌握發生於資訊生產者與消費者和系統本身之間的互動。

從一個定義的動作者的觀點用直接的語言描述特定的使用情境。

2828

發展活動圖

在特定情境中， UML 活動圖表藉由提供互動流向 (flow) 的圖形表示支援使用案例。

一個活動圖以圓角長方形表示某個特定的系統功能，箭頭表示經過系統的流程，決策的菱形描述某個分支決定，並且水平的實線指示平行活動的發生。

2929

泳道圖

UML泳道圖 (swimlane diagram) 是活動圖的一種有用的變化。

讓塑模者表示由使用案例所描述的活動流向 (flow) 指出那個參與者或分析類別對活動長方形所描述的動作具有責任。

責任以垂直分割圖表的平行線段表示，如同游泳池中的泳道。

3030

流程導向塑模 資料的流程導向塑模仍然是現今最為廣泛使用的分析記號。 雖然資料流程圖 (data-flow diagram, DFD) 與相關的圖表與訊息並不是正式 UML 的一部份，但它們能輔助 UML 圖，並提供額外對系統需求與流程的洞察力。

3131

資料流程圖 (DFD)

資料流向圖能讓軟體工程師同時發展資訊領域與功能領域的模型。 DFD採用輸入 - 處理 -輸出的系統觀點。

即資料物件流入軟體，再由處理元素轉換，並且成為結果的資料物件將流出軟體。

資料物件由標示的箭頭所表示，而轉換則以圓圈表示。

DFD 以階層的形式呈現。 第一個資料流程模型 ( 有時稱為第 0 層級的 DFD 或環境圖表示整體的系統。

接下來的資料流程圖改進環境圖，以提供增加的細節給接下來的每個層級。

3232

控制流程模型

對於許多類型的應用程式，資料模型與資料流向圖是獲得有意義洞察軟體需求所必需要的。

某一類型的應用程式是由事件而非資料所「驅動」、產生控制訊息而不是報表或顯示和強烈關心時間與效能的流程訊息。

除了資料流向塑模外，此類應用程式需要控制流向塑模的使用。

3333

類別為基礎的塑模

要如何發展分析模型中類別基礎元素 類別與物件、 CRC 模型和合作圖。

3434

分析類別的選擇 ( 一 )

分析類別 (analysis classes) 以下列其中的一種方式宣告它們： 由以電腦為基礎的系統所使用還來產生或消費資訊的外部實體 (例如，其他的系統、裝置、人 ) 。

問題資訊領域的部份事物 (例如，報表、顯示、文字 letters 、訊號 ) 。

發生於系統運作環境中的事故或事件 (例如，性質轉換或完成一系列的機器人動作 ) 。

3535

分析類別的選擇 ( 二 )

與系統互動的人所扮演的角色 (例如，經理人、工程師、售貨員 ) 。

與應用程式相關的組織單位 (例如，組、團、隊 ) 。

建立問題環境和系統整體功能的場所 (例如，製造地點或碼頭 ) 。

定義物件的類別或相關物件的類別的結構 (例如，感應器、四輪車輛或電腦 ) 。

3636

分析類別選擇的特徵 Coad 和 Yourdon 建議使用的六種選擇特徵，可以作為分析師在分析模型中考慮每個潛在類別：

保留訊息 (Retained information) 需要的服務 (Needed services) 多重屬性 (Multiple attributes) 共同屬性 (Common attributes) 共同的操作 (Common operations) 基本的需求 (Essential requirements)

3737

類別 -責任 -合作者 (CRC)塑模

類別 -責任 - 合作者 (CRC) 塑模提供一個簡單的方法來辨識與組織相關於系統或產品需求的類別。

Ambler 以下列的方式描述 CRC 塑模： 一個 CRC 模型是真正代表類別的標準索引卡的整體。

卡片可區分為三類。

3838

類別 -責任 -合作者 (CRC) 索引卡片

CRC 模型可以使用作為真實或虛擬的索引卡片。其意圖是發展一種組織的類別表示。責任 (responsibilities) 是相關於類別的屬性與操作。

合作者 (collaborators) 是那些必要的類別，以提供一個類別具有完成責任所需的資訊。

3939

產生行為模型

類別圖、 CRC索引卡片和其他以類別為導向的模型表示分析模型的靜態元素。

為將轉移到系統或產品動態行為。 我們必須要表示系統的行為成為特定事件與時間的函式。

4040

行為模型 (behavioral model)

行為模型說明軟體將如何回應外部的事件或激勵。要創造這個模型，分析師必須要實行下列的步驟：

評估所有的使用案例以完全地瞭解在系統中互動的順序。

辨識驅動互動順序的事件，並瞭解這些事件如何與特定的類別相關。

為每種使用案例創造順序。 為系統建立狀態圖。 檢視行為模型以確認準確度與一致性。

4141

狀態表示法 在行為塑模的環境中，必須要考慮二種不同狀態的特性：

當系統實行其功能時，每個類別的狀態。 當系統實行它的功能時，作為外部所觀察到的系統狀態。

類別的狀態具有被動與主動的特性。 被動的狀態 (passive state) 單純的只是一個物件的屬性所有目前的狀態。

物件的主動狀態指出當它歷經連續的轉換或處理後，物件目前的狀態。

4242

分析類別狀態圖 一個行為模型的元件是一個 UML 的狀態圖，此狀態圖表示每個類別的主動狀態和造成這些主動狀態之間改變的事件。

4343

順序圖

它指出事件如何造成從物件到物件的轉移。 一旦事件藉由檢查使用案例而確認時，塑模者將創造一個順序圖 - 說明事件作為時間的函數時，如何造成物件到物件的流動。

順序圖是使用案例的速記的版本。 它表示出關鍵的類別和造成類別到類別流動的行為事件。

4444

Q&A

敬請指教