元件层级的设计问题.ppt

警報管理元件的PDL 11.5.4 設計記號的比較 設計記號應該導致一個很容易瞭解與討論的程序表示法。 記號應該強化「編碼成為(code to)」的能力，使得程式碼事實上成為一個自然的設計產物(by-product of design)。 設計表示法必須能很容易地維護，使得設計總是可以正確地表示出程式。 設計記號的問題 在任何設計記號的討論中，會自然出現的一個問題是： 對於上述所提及的屬性，什麼樣的記號才是最好的？ 此問題的任何答案都是主觀與開放而可以辯論的。 它顯現出程式設計語言所提供最好的特性組合。 PDL或許可能直接地被崁入到來源列表(source listings)中，改善文件並使得設計維護變得較為不困難。 編輯可以使用任何的文字編輯器或文書處理系統來完成，自動的處理器也已經存在，且「自動程式產生器」的可能性也是很好的。 設計記號的問題 活動圖與流程圖的圖表式性質在控制流向上提供許多設計者所喜愛的一種觀點。 決策表格精確表格化的內容對表格所主導的應用程式是一項優良的工具。 許多沒有在本書中所提及的其他設計顯示方法(例如Petri nets)，都提供它們自己獨特的好處。 在最後的分析中，設計工具的選擇或許比技術上的屬性更緊密地與人為因素相關。 定義設計類別的操作 第一次反覆定義每個設計類別的操作。 操作應該以確保高度凝聚的方式進行特性化； 操作應該執行單一目標的功能或子功能。 下一次反覆則做得比擴展操作名稱還要多。 例如，圖11.1所提及的computePaperCost()操作可以下列的方法擴展： computePaperCost(weight, size, color): numeric 這指出computePaperCost()需要重量(weight)、尺寸(size)和顏色(color)屬性做為輸入，並回傳做為輸出的數值(實際上為價格) 。 如果實作computePaperCost()所必要的演算法很簡單且廣泛地被瞭解，則進一步的細化就不需要。 程式碼設計前的操作細化 進行程式碼設計的軟體工程師將提供實作操作所需要的細節。 如果演算法更為複雜或晦澀難解，則在此階段更進一步的設計細化就是需要的。 圖11.8為 computePaperCos()描繪一個UML活動圖。 當活動圖使用於元件層級設計規格時，它們通常在比原始碼略高的抽象化層級上表示。 一種可替代的方法-使用虛擬碼做為設計規格。 圖11.8 computePaperCost()的UML活動圖 元件層級設計的典型任務組 步驟4　描述持續的資料來源(資料庫與檔案)並確認所需要管理它們的類別。 資料庫與檔案通常超越個別元件設計的描述。 大部分的情形中，這些持續的資料儲存最初都被指明做為架構設計的一部分。 在設計細化進行時，它常用來提供關於這些持續資料來源結構與組織的額外細節。 元件層級設計的典型任務組 步驟5　為一個類別或元件發展與細化行為的表示。 使用做為分析模型一部分的UML狀態圖表示外部可觀察的系統行為，和個別分析類別更為局部化的行為。 在元件層級設計期間，它有時必須要模塑類別的行為。 物件的動態行為與狀態圖 一個物件(當程式執行時一個設計類別的實例)的動態行為會由外部的事件和物件的目前狀態(行為的模式)所影響。 要瞭解一個物件的動態行為，設計者必須檢查所有相關設計類別整個生命期間的使用案例。 當時間過去而發生事件時，這些使用案例提供資訊以協助設計者描繪影響物件和物件所駐留狀態的事件。 在狀態(活動驅使)之間的轉移使用如圖11.9的UML 狀態圖表示。 圖11.9 PrintJob類別狀態圖的片段 狀態移轉的表示方式 從狀態(以圓角長方形所表示)到另外一個狀態移轉(transition)的發生，將成為採取以下形式的事件的結果： 事件名稱(參數列)[護衛條件] / 動作表示 事件名稱(event-name)識別活動； 參數列(parameter-list)併入與事件相連結的資料； 護衛條件(guard-condition)以物件限制語言(OCL)編寫，並指明在事件發生之前所必須要被滿足的條件； 在移轉發生時，動作表示(action-expression)定義一個發生的動作。 狀態移轉範例 參考圖11.9，每個狀態可以定義進入(entry)/與離開(exit)動作，它們會在移轉進入或離開狀態時發生。 這些動作對應到正被塑模的相關類別的操作。 做/(do/)的指示提供一個機制，以指出發生在狀態中的活動， 包括/(include/)的指示藉由在狀態的定義中崁入更多的狀態圖細節以細化行為。 行為的模型時常包含其他設計模型中不明顯的資訊。 例如，小心的檢查圖11.9中的狀態圖以指出PrintJob類別的動態行為是附隨著二位顧客所同意印刷工作的價格和