第七章uml活动图 在uml的工具中，提供了活动图（activity diagram

第七章uml活动图 在uml的工具中，提供了活动图（activity diagram 第七章 UML活動圖 , 在UML的工具中,提供了活動圖:activity diagram:工具,使用圖形的 表 关于同志近三年现实表现材料材料类招标技术评分表图表与交易pdf视力表打印pdf用图表说话 pdf 示方式,較能夠清楚表現使用者和系統間互動的 流程 快递问题件怎么处理流程河南自建厂房流程下载关于规范招聘需求审批流程制作流程表下载邮件下载流程设计 。 , 活動圖:用來描述工作流程:workflow:的圖形,在圖中包括了不同的系 統活動、執行活動的人和活動順序流程 活動圖的基本符號: , 活動和動作:使用橢圓形符號表示活動:activity:或動作:action:,並在 橢圓形中標示活動名稱或動作指令。 ? 活動是一連串動作的集合,可以再細分,動作指令則是最基本的單 位,不可以再細分。 , 轉換箭號:transition::活動符號上邊和下邊的箭號線,表示從上一活動 轉換至下一個活動。 , 決策:用來表示工作流程中的控制,以菱形符號表示,從菱形符號中會分 出兩條以上的轉換箭號,在轉換箭號旁要加上條件控制,以「[ ]」表示。 , 同步橫條:用來分隔:split:不同活動的路徑或將不同活動的路徑整合 :join:到同一活動。 , 起始和終止狀態符號:為表示一個工作流程的起始和終止。 ? 起始符號以實心的黑圈表示,而終止符號則是在實心的黑圈外再加 上一個圓圈。 , 責任區:利用一個長方形的區塊來表示這個區塊中的活動是由什麼人或什 麼單位負責執行,這樣的長方形的區塊稱之為責任區:swimlane:。 活動 , 活動圖也可以像使用案例擁有前置條件與後置條件。 , 活動圖通常以一個控制節點起頭,是活動起始點。 , 活動結束於一或數個結束節點。 , 活動圖能給我們更多資訊,更圖形化的使用案例。 節點 , 物件節點可代表特定類詞的實例,並可表示在活動的特定點為可使用的。 , 物件節點的輸入邊與輸出邊稱為物件流程。代表物件在活動裡的走向。 , 物件節點在任一個輸入邊收到物件符記,所有輸出邊要同時互相競爭得取 這個符記。 第八章 UML領域模型 , 領域模型:以圖形的方式表現出從使用案例文字中找出物件與物件間的關 係,並確認此圖形能對等於使用者的需求。 , 領域模型:領域中真實世界物件或概念類別的視覺呈現。 ? 分析階段找出來的這些物件,稱之為概念:concept:或概念類別, 這個圖形的表示即稱之為初步類別圖。 , 描繪領域模型時,除了找出與問題相對應的概念類別外,還要尋找出這個 概念類別的屬性與關聯。 ? 屬性:物件中的邏輯資料 ? 關聯:兩種概念類別的實例中存在著有意義的連結 概念類別符號 , 在UML中表現概念類別的符號就是使用一長方形符號,在長方形符號中 加上類別名稱,如果有需要的話,可以分成兩部份,第二部份即可記錄類 別的屬性。 關聯符號 , 關聯的主要功能是要清楚的說明物件間的語意關係。 ? 關聯符號包括三部份 , 第一部份為關聯名稱,通常使用動詞 , 第二部份為關聯間的多重性 , 第三部份為方向箭號,它僅是用來表示關聯名稱閱讀的方 向,有時候會被省略 降低呈現上差距 ?設計模型盡量使用領域模型的名稱以減少兩者之間的差異。 建構領域模型主要工作就是尋找概念類別、尋找關聯和尋找類別屬性。 第九章 系統循序圖與合約 , 系統行為 ? 把系統當作「黑箱」,研究並定義他的行為。 ? 系統行為裡面描述系統該做些什麼,而不是解釋它是如何辦到的。 , 系統循序圖 ? 系統循序圖裡面展現使用案例中某個特別情節,外部參與者所產生 的事件,事件發生順序以及系統之間的事件 ? 通常只畫出使用案例的主要成功情節與常發生或複雜的替代情節 , 系統事件 ? 在使用案例中,外部參與者會與軟體系統互動,互動過程中,參與 者會對系統產生事件,而且通常會要求執行某種操作以回應事件。 ? 系統事件命名,應以動詞開頭。 ? 用抽象:高階:層次替事件命名 , 系統操作 ? 把系統視為黑盒子,裡面式系統為了處理系統事件而提供的公開介 面,此介面即一組統操作的集合 ? 系統操作會處理外部輸入的系統事件 , 操作合約 ? 合約用來定義系統操作,它利用系統操作執行後的領域模型狀態的 變化來描述系統行為中的細節。 , 合約中的各個小節 ? 操作:操作名稱與參數 ? 交互參考:這個操作位於哪個使用案例 ? 事先條件:執行操作之前,值得注意的一些假設,其中包括系統或 物件的狀態 ? 事後條件:完成操作後的領域模型物件狀態 , 事後條件 ? 事後條件裡面會描述領域模型中物件狀態改變,此改變包括實例的 產生、關聯的產生與中斷、屬性的修改 ? 描述系統操作所需的狀態變化而不描述要如何設計這些東西 ? 事後條件提供分析後的細節,明確宣告操作所必頇達成的外顯結果 第十章 互動圖:溝通圖與循序圖 物件設計所需的基本相關知識包括 1. 指派責任原則 2. 設計樣式 , 溝通圖(Communication diagrams) ? 溝通圖是互動圖的一種,它強調參與互動的物件組織,透過溝通圖 可以將物件間的連結以及訊息收送情形顯示出來。 , 循序圖 (Sequence diagrams) ? 循序圖也是互動圖的一種,基本上循序圖與合作圖表達了相同的意 義,但卻以另一種觀點來構圖,循序圖顯示了所選擇物件集合在某 段時間限制的情形,一連串的訊息交換,它強調了事件路線的前後 順序。 ? 第十一章 類別圖 , 類別圖 (Class diagrams) ? 顯示類別及彼此之間的關係。 , 類別圖的三種觀點 ? 概念性觀點 , 在此觀點,類別圖代表領域裡面的概念,這些概念雖會跟實 作它們的類別相關,可是卻經常沒有直接的對應關係,它可 以從與程式語言無關的方面去思考。 ? 規格觀點 , 此觀點將焦點放在軟體上,但只注意軟體的介面而不是實 作,規格觀點強調物件的責任,物件導向開發工具十分強調 介面與實作之間的不同,其中類別的介面可稱之為型態,型 態可以由很多種類別實作出來,而一個類別也可以實作出許 多的型態。 ? 實作觀點 , 在這個觀點的重點為類別,且直接討論到實作面。 , 名稱 ? 命名習慣為類別名稱開頭大寫 ? 簡單名稱 , 屬性 ? 命名習慣為屬性名稱開頭小寫 ? 一般格式 屬性名稱:型態,初始值 ? 標記值 (Tagged value) 用來規範額外特殊的屬性,置於大括號之內 類別關聯性(畫法看小考考券背面) 方向、限定、屬性、聚合、複合、一般化、實現 第十二章 GRASP分配責任樣式 , 樣式 ? 用結構化的格式描述一般性的設計原則與慣用 方案 气瓶 现场处置方案 .pdf气瓶 现场处置方案 .doc见习基地管理方案.doc关于群访事件的化解方案建筑工地扬尘治理专项方案下载 的問題與解決 方案 例:樣式名稱:資訊專家樣式 解決方案:把責任指派給擁有相關資訊的類別 樣式所解決的問題:指派物件責任的基本原則 , 樣式的注意事項 ? 樣式是會重複出現的 ? 樣式必頇有名稱 ? 替樣式命名有助於改善溝通 , 什麼是GRASP? ? General Responsibility Assignment Software Patterns的縮寫 ? GRASP樣式裡面用樣式的形式事描述基本物件設計原則與指派責 任原則 , 基本的GRASP樣式 , 資訊專家樣式(information expert) , 造物主樣式:creator: , 低耦合力樣式(low coupling) , 高內聚力樣式(high cohesion) , 資訊專家樣式(information expert) ? 問題 , 指派物件責任的通則為何? ? 解決方案 , 把責任分派給資訊專家,因為他擁有必要的資訊 ? 注意事項 , 開始指派責任之前,先清楚描述責任 , 分析哪些類別擁有必要資訊時,要看領域模型還是設計模 型, 答:1. 如果設計模型中有相關類別,就先看設計模型 2. 否則請看領域模型,並嚐試用這個概念產生相對應的設計類別 , 優點 , 專家樣式可以維持資訊封裝,因為物件用自己的資訊完成工 作:較低耦合力:。 , 行為分散到擁有必要資訊的類別身上,可能產生更多具內聚 力的“輕量級”的類別定義。 , 造物主樣式:creator: , 問題 , 誰應該負責產生某些類別的新實例, , 解決方案 , 如果下面任何一個情況成立的話,把產生類別A實例責任 交給類別B 1. B中聚合A的物件 2. B包含A的物件 3. B負責紀錄A的物件實例 4. B密切用到A的實例 5. B中有產生A時會用到的初始化資料 , 優點 ? 造物主樣式的設計結果將具有低耦合力:因造物主可能早就看得見 被產生者:。 , 低耦合力樣式(low coupling) ? 問題 , 如何讓元素之間的相依性小,並且在增加再使用性 ? 解決方案 , 指派責任後,不會提高耦合性 , 優點 ? 不受其它合成關係變動的影響 ? 簡單、易於個別了解 ? 方便再使用 , 高內聚力樣式(high cohesion) ? 問題 , 如何把複雜度保持在可管理的範圍內, ? 解決方案 , 指派責任後仍然維持高內聚力 , 優點 ? 提高設計的清晰度與可理解性 ? 簡化維護與加強功能時的開發工作 ? 通常也會具低耦合性 ? 少許高度相關的功能性可以增加再使用性 , 控制者樣式(controller) ? 問題 , 誰應該負責系統輸入事件, ? 解決方案 , 把接收或處理系統事件指派到代表下面概念的類別化 , 代表整個系統、裝置或子系統:表層介面控制者: , 一個命名為使用案例名稱+Handler的類別,並且對 此使用案例的所有系統事件用同樣的控制者:使用案 例控制者: ? 注意事項 , 一般來說,控制者應該把需要完成的工作委託給其他物件 做,它則負責協調並控制整個活動。 , 優點 ? 增加再使用與可嵌入式介面的可能性 ? 存放使用案例狀態的合理位置 , 合約與使用案例實現 ? 針對每個系統操作,我們會寫出合約,並以事後條件說明領域模型 狀態的改變。 ? 針對事後條件的描述,我們可以設計出滿足需求之互動情形,以達 成使用案例實現。 , 注意事項 ? 需求是不完美的:之前所寫的使用案例與合約只是對想達事務的一 種猜測,我們需要使用者及領域專家的持續參與。 ? 反覆式開發方式的精神就是在需求分析時捕捉“合理的”資訊明細 程度,然後在設計與實作再捕捉更多的細節。