UML · 系統與概念筆記

使用案例圖主要的目的在幫助開發團隊設想系統功能的需求，其中包含了參與 ... 然而實作類別圖將不會寫上相同的屬性欄位(attributes)，因為實作類別極有可能會使用到像 ... 系統與概念筆記 Introduction Summary 資訊安全 What'sInformationSecurity Attack DDoS 使用者端防護 X-Frame-Options 參考 檢測 網路效能 iperf 程式概念 命名規則 RESTful UML UseCase PoweredbyGitBook UML UML 圖例 [UseCasediagram]使用圖例 目的: 用來說明系統所提供的一項功能， 使用案例圖主要的目的在幫助開發團隊設想系統功能的需求，其中包含了參與者（actor，也就是跟系統互動的人）與基本處理程序的關係，還有不同使用案例之間的關係。

繪製 人物:參與者 橢圓:使用案例的名稱 線:表示參與者與使用者案例有關係 使用案例圖通常會表示出一組使用案例：不是整個系統所有的使用案例，就是與使用案例相關的一組特殊的功能（例如所有和安全管理相關的使用案例）。

你必須在圖的中間畫一個橢圓，並在橢圓的中間或是下面填入這個使用案例的名稱，用來表示使用案例圖中的一個使用案例。

另外你要在圖的左邊或是右邊畫一個棒狀的小人（為了避免你會納悶，事實上有一些人會畫比棒狀小人好看的人形圖），用來表示使用案例圖的一個參與者（包括系統使用者）。

還要利用簡單的線條來描述參與者和使用案例之間的關係。

[Classdiagram]類別圖 目的 描述不同的個體（人、事物和資料）相互的關係；它表示了系統的靜態結構。

類別圖能夠用來表示邏輯類別， 通常也就是組織裡面的業務人員所談論的東西：搖滾樂團、CD、收音機；或是貸款、住宅抵押、汽車貸款和利率。

類別圖也能夠用來表示實作的類別， 也就是一般程式設計師所要處理的物件。

實作的類別圖有可能跟邏輯的類別圖使用一些相同的類別。

然而實作類別圖將不會寫上相同的屬性欄位(attributes)，因為實作類別極有可能會使用到像是Vectors和HashMaps這類東西。

類別繪製 在類別圖中描繪的類別，是一個有三個水平區域的長方形。

上方的區域表示類別的名稱； 中間的區域包含了類別的屬性欄位； 下面的區域包含了類別的操作（或是方法）。

關係繪製 繼承關係:一條頂端有箭頭的線(箭頭空心) 聯繫（association）關係:兩個類別互相知道對方的聯繫（association）關係，是一條實線 箭頭實線:只有一方知道另一方類別的聯繫關係，就一條有開放箭頭的實線。

1對1:1 1對多:1..* 上面範例，我們觀察到繼承關係和兩個聯繫關係。

CDSalesReport類別繼承了Report類別， CDSalesReport聯繫到一個CD， 但是CD類別不知道任何有關CDSalesReport類別的資訊。

CD和Band類別互相知道對方，兩個類別都以多對多的方式互相聯繫到對方。

[Sequencediagram]循序圖 循序圖描述特定使用案例或是特定使用案例的一部份詳細的流程。

它們大多能讓人望圖生義；並可以依照順序描述不同物件之間的呼叫關係，也能夠詳細地描述給不同物件的各種呼叫。

循序圖有兩個象限： 垂直象限: 依照訊息/呼叫發生的時間順序，來描述訊息/呼叫的先後次序； 水平象限: 則描述一個物件實體（instances）傳送訊息給哪一個物件實體。

繪製 物件實體（instances）: 每一個實體為一個T，在方格內填入實體名:類別名 類別與實體中間插入(空白/冒號/空白:) 例如myReportGenerator:ReportGenerator 類別實體呼叫類別實體:一條有開放箭頭的實線，指到接收端的類別實體 在這條線的上面填入訊息/方法的名稱。

訊息傳遞 對於重要的訊息，你也可以畫上有箭頭的虛線，指回訊息來源的類別實體； 在虛線上標示回傳值。

如何閱讀? 一開始，從左上方角落那個”驅動者（driver）”類別實體開始引發一連串的事件， 然後跟著圖往下追蹤每一個訊息。

要記住：即使在圖4循序圖範例對每一個傳送的訊息都繪製了回傳訊息，但這是可做可不做的。

上圖可以了解到要如何建立一份CD銷售報表。

aServlet物件是我們範例中的驅動者， aServlet會傳送一個訊息給稱為gen的ReportGenerator類別實體， 這個訊息被標示為generateCDSalesReport，這個名稱代表它是由ReportGenerator物件實作的訊息處理器， 再更詳細地檢視這個訊息，generateCDSalesReport訊息的括號裡面有一個cdId的標記，這表示aServlet會在這個訊息裡面附帶傳送一個稱為cdId的變數。

當gen實體傳送一個generateCDSalesReport訊息，接下來gen會呼叫CDSalesReport類別，會傳送回來一個稱為aCDReport的CDSalesReport實體。

然後gen實體會呼叫回傳的aCDReport實體，再利用每一次的訊息呼叫把參數傳給aCDReport。

在這個序列的最後，gen實體會回傳aCDReport給它的呼叫者aServlet。

請注意：上圖的循序圖對常見的循序圖來說有一點太詳細了，然而，我相信它還是很簡單易懂，同時該圖也展示巢狀呼叫怎樣畫。

另外對於資淺的開發人員來說，有時候也必須要深入每一個程序，描述越詳細清楚，越能幫助開發人員了解他們應該要做什麼。

[Activitydiagram]活動圖 目的 活動圖用來描述在進行一項活動時，兩個或是多個類別物件之間程序的控制流程。

活動圖能夠用來描述在商業單元階層的高階商業程序，也可以用來描述低階內部類別的行為。

以我的經驗來說，活動圖最好是用來描述高階處理程序， 例如目前公司要如何處理商務程序，或是它要怎麼做生意。

這是因為跟循序圖比較起來，活動圖在表面上看來比較”不專業”，另外業務人員會比較快速且容易瞭解這個圖的意義。

繪製 (類似狀態圖) 實心圓圈:活動開始，連接到起始的活動。

活動:圓角的矩形，裡面填上活動的名稱。

轉換線:活動可以透過轉換線連接到其他不同的活動上，也可以連接到決策點上，然後連到有決策點把關的其他活動上。

雙圓:終結所有模擬程序的活動 水道(swimlane):可以使用水道(swimlane)分出不同的群組，用來表示物件實際上要怎麼執行這個活動 上圖我們用兩個水道（swimlane），因為我們有兩個物件控制不同的活動：一個樂團經理人和一個報表工具。

整個程序是由樂團經理人選擇要看哪一個樂團的銷售報表開始， 接下來報表工具會取得並展示該經理人所管理的所有樂團，並詢問他要選哪一個。

在樂團經理人選擇了一個樂團之後，報表工具會取得銷售的資訊並展示這個銷售報表。

根據活動圖的描述，展示報表是這個程序的最後一個步驟。

參考 DonaldBell(譯:姚長利)-UML入門：統一建模語言入門 http://www.dotspace.idv.tw/Jyemii/umlcolumn/articles/umlwriting/UMLBasics/UMLBasics.htm resultsmatching"" Noresultsmatching""