分析塑模方法的流程.pptVIP

QA 撰寫使用案例 使用案例可以掌握發生於資訊生產者與消費者和系統本身之間的互動。 從一個定義的動作者的觀點用直接的語言描述特定的使用情境。 發展活動圖 在特定情境中，UML活動圖表藉由提供互動流向(flow)的圖形表示支援使用案例。 一個活動圖以圓角長方形表示某個特定的系統功能，箭頭表示經過系統的流程，決策的菱形描述某個分支決定，並且水平的實線指示平行活動的發生。 泳道圖 UML泳道圖(swimlane diagram)是活動圖的一種有用的變化。 讓塑模者表示由使用案例所描述的活動流向(flow) 指出那個參與者或分析類別對活動長方形所描述的動作具有責任。 責任以垂直分割圖表的平行線段表示，如同游泳池中的泳道。 流程導向塑模 資料的流程導向塑模仍然是現今最為廣泛使用的分析記號。 雖然資料流程圖(data-flow diagram, DFD)與相關的圖表與訊息並不是正式UML的一部份，但它們能輔助UML圖，並提供額外對系統需求與流程的洞察力。 資料流程圖(DFD) 資料流向圖能讓軟體工程師同時發展資訊領域與功 能領域的模型。 DFD採用輸入-處理-輸出的系統觀點。 即資料物件流入軟體，再由處理元素轉換，並且成為結果的資料物件將流出軟體。 資料物件由標示的箭頭所表示，而轉換則以圓圈表示。 DFD以階層的形式呈現。 第一個資料流程模型(有時稱為第0層級的DFD或環境圖表示整體的系統。 接下來的資料流程圖改進環境圖，以提供增加的細節給接下來的每個層級。 控制流程模型 對於許多類型的應用程式，資料模型與資料流向圖是獲得有意義洞察軟體需求所必需要的。 某一類型的應用程式是由事件而非資料所「驅動」、產生控制訊息而不是報表或顯示和強烈關心時間與效能的流程訊息。 除了資料流向塑模外，此類應用程式需要控制流向塑模的使用。 類別為基礎的塑模 要如何發展分析模型中類別基礎元素 類別與物件、CRC模型和合作圖。 分析類別的選擇(一) 分析類別(analysis classes)以下列其中的一種方式宣告它們： 由以電腦為基礎的系統所使用還來產生或消費資訊的外部實體(例如，其他的系統、裝置、人)。 問題資訊領域的部份事物(例如，報表、顯示、文字letters、訊號)。 發生於系統運作環境中的事故或事件(例如，性質轉換或完成一系列的機器人動作)。 分析類別的選擇(二) 與系統互動的人所扮演的角色(例如，經理人、工程師、售貨員)。 與應用程式相關的組織單位(例如，組、團、隊)。 建立問題環境和系統整體功能的場所(例如，製造地點或碼頭)。 定義物件的類別或相關物件的類別的結構(例如，感應器、四輪車輛或電腦)。 分析類別選擇的特徵 Coad和Yourdon建議使用的六種選擇特徵，可以作為分析師在分析模型中考慮每個潛在類別： 保留訊息(Retained information) 需要的服務(Needed services) 多重屬性(Multiple attributes) 共同屬性(Common attributes) 共同的操作(Common operations) 基本的需求(Essential requirements) 類別-責任-合作者(CRC)塑模 類別-責任-合作者(CRC)塑模提供一個簡單的方法來辨識與組織相關於系統或產品需求的類別。 Ambler以下列的方式描述CRC塑模： 一個CRC模型是真正代表類別的標準索引卡的整體。 卡片可區分為三類。 類別-責任-合作者(CRC)索引卡片 CRC模型可以使用作為真實或虛擬的索引卡片。其意圖是發展一種組織的類別表示。 責任(responsibilities)是相關於類別的屬性與操作。 合作者(collaborators)是那些必要的類別，以提供一個類別具有完成責任所需的資訊。 產生行為模型 類別圖、CRC索引卡片和其他以類別為導向的模型表示分析模型的靜態元素。 為將轉移到系統或產品動態行為。 我們必須要表示系統的行為成為特定事件與時間的函式。 行為模型(behavioral model) 行為模型說明軟體將如何回應外部的事件或激勵。要創造這個模型，分析師必須要實行下列的步驟： 評估所有的使用案例以完全地瞭解在系統中互動的順序。 辨識驅動互動順序的事件，並瞭解這些事件如何與特定的類別相關。 為每種使用案例創造順序。 為系統建立狀態圖。 檢視行為模型以確認準確度與一致性。 狀態表示法 在行為塑模的環境中，必須要考慮二種不同狀態的特性： 當系統實行其功能時，每個類別的狀態。 當系統實行它的功能時，作為外部所觀察到的系統狀態。 類別的狀態具有被動與主動的特性。 被動的狀態(passive state) 單純的只是一個物件的屬性所有目前的狀