企業塑模的觀念

在這一章節，我們將討論一些在企業塑模裡的基本觀念。像企業參與者、企業工作者、和活動圖的概念，此將有助於我們了解組織本身。在這個章節，將包括下列觀念：

• 企業參與者(Business Actors)

• 企業工作者(Business Workers)

• 企業使用案例(Business Use Cases)

• 企業使用案例圖(Business Use Case Diagrams)

• 企業使用案例與企業參與者間的聯絡關係

• 企業實體(Business entities)

• 活動圖(Activity Diagrams)

再次提醒，記住「企業塑模」並非關注於什麼要自動化和什麼不要自動化（雖然在工作流程中可以發現這些資料）。反而，我們要關注在另外兩個地方，第一，了解什麼是組織的邊界範圍，和它需跟誰聯絡溝通？第二，什麼是組織內的工作流程，和如何將它們最佳化？

企業參與者

企業參與者是處於組織外部，然而跟組織有相互影響的任何人或任何事。例如，企業參與者可能是公司的客戶、債權人、投資人，或是供應商，每個參與者對公司的活動皆感興趣。

在 UML 裡，企業參與者是用下面的圖示來表示：

雖然此圖示看起來像一個人，然而企業參與者不必需是個「個人」，它可能表示一群人或一家公司。我們針對企業參與者塑模，是為了瞭解「誰」和「何事」需要跟業務相互影響，及「如何」跟業務相互影響。當我們在進行再造程序或建立新系統時，我們必需常常記住，組織必需更加迎合外界實體的需求。藉由免除現金簿而改善流程提升效率，對一家雜貨店有什麼好處？當然，這是一個極端的例子，但同樣的觀念：我們必需謹記為什麼此業務會是第一順位。企業參與者塑模可幫忙達成此效果。

企業工作者

企業工作者是組織內部的一個角色(role)，注意企業工作者是指角色，而非指職務(positions)。一個人可以扮演好幾個角色，但祗能擔任一個職務。以角色為主而非以職務為主的好處是，職務會因時間而改變，但角色依舊不變。

在 UML 裡，企業工作者是用下面的圖示來表示：

我們塑造企業工作者模型是為了瞭解企業內部的角色，和他們之間如何互動。經由描述每一個企業工作者，我們可以了解那些角色需負什麼樣的責任、需要有什麼樣的技能，以及其他細節。對於企業工作者，我們至少要考慮下列事項：

• 這些工作者的職責是什麼？

• 這些工作者需要有什麼樣的技能來完成這個職責？

• 跟其他的工作者有什麼互動？

• 參與那一方面的工作流程？

• 每個工作者在每個工作流程中擔負什麼樣的職責？

企業使用案例

企業使用案例是一群與組織裡有關的工作流程，它會對企業參與者產生「價值」。換句話說，企業使用案例告訴讀者，組織是在做什麼。更明確的說，它告訴某些人，組織對與它互動的企業及個人，提供了那些價值。這幅有關組織的所有企業使用案例，必需完整的描繪出企業在做什麼。

一個有關零售店的企業使用案例範例，可能包括「進貨存貨清單」、「訂定產品價格」、「銷售產品」、「退款」或「運送產品」。對一個電子商務化的公司，可能包括「註冊成使用者」、「產生∕修改訂單」、「填寫訂單」、「 進貨存貨清單」、「取消訂單」。一個投資機構可能有「買進股票」、「出售股票」。除此之外，甚至把一家沒有相當自動化的公司，仍可運用企業使用案例。一個畜牧場也有企業使用案例，像「買進家畜」、「出售家畜」、「瓶裝牛奶」、或「補充飼料」。

在 UML 裡，我們用下面的圖示來表示：

企業使用案例通常是用下列格式命名「＜動詞＞＜名詞＞」，如「訂定產品價格(Price Products)」。這是一個好的格式乃基於下列幾點原因，它保持企業使用案例的一致性，即使有多位分析師同時定義它們。同時，它使企業使用案例容易讓終端使用者了解。單獨一個 「Price」 並不能告訴使用者有關此業務更多，同樣使用 「Products」 也不能。或許最重要的是，最後它不斷地集中重點在於「什麼是公司要做的」，即是「什麼是公司要完成的」，而不完全是其使用的企業實體而已。

當然，沒有詳細的說明，甚至連 「Price Products」 也不能告訴我們更多訊息。每一個企業使用案例，你應該產生某些型式的報告，讓人們明確地知道在使用案例裡面有那些事發生。有沒有職員用歷史的價格來設定現在的價格？他們有沒有使用問卷來確定什麼是客戶願意付的價格？他們有沒有更深入的研究，每項產品在埃及和土耳其的價錢，然後把兩者平均一下？或者，他們是隨意訂產品價格？我們不能確信完全了解它，除非此特別的工作流程在某個地方備有文件說明。

寫這些工作流程的文件有幾種方法，在某些情況下，最簡單的方法就是依編號順序，一步一步將使用案例所發生的經過一條條列舉出來：

1. 職員跟經理討論，而獲得所有要訂價的新產品清單。

2. 職員核對商店的採購記錄，看看為每個新項目付了多少錢。

3. 職員把採購價格加上 10% 以成為此項目的單價。

4. 職員把新價格送給經理批准。

5. 假如經理不同意，職員跟經理對新價格作出決議。

6. 職員為每個項目做一個價格標籤。

7. 職員把價格標籤貼到每個項目上。

這種方法的問題是，如果有很多的條件邏輯分岐，會讓閱讀者感到迷糊。像上面這個簡單的例子，這種情況還算容易了解。不幸的是，真實的商業世界不會永遠這麼簡單。一個企業工作者在 A 情況發生時，可能執行一些動作，在 B 情況發生時執行另一些動作，在 C 情況發生時，又要執行另外的動作。在這種情形下，如果使用活動圖會比較有利。

活動圖是用圖型來表示工作流程的步驟是什麼，步驟的順序是如何，和誰有責任來執行每個步驟。對於上面所描述的工作流程，一個簡單的活動圖看起會像圖 3.1

FIGURE 3.1 Activity diagram

　

在這個章節的後面，我們將討論活動圖，包括出現在圖中各種不同的符號，現在，我們祗看看此圖所表達的訊息。如先前所示，我可以看到訂價的步驟是什麼，但用圖來表示可讓人容易閱讀和了解，讓我們對大且複雜的工作流程會有更深刻的印象。

企業使用案例圖

企業使用案例圖向你展現有關組織的企業使用案例、企業參與者、企業工作者和他們之間的互動。它給你一個完整的模型，讓你了解公司在做什麼，在公司裡面有誰，在公司外面有誰，它給你一個組織的範圍，讓你了解組織包含那些事，它的邊界在那裡。

一個企業使用案例圖的例子如圖 3.2 所示：

這個圖型是故意簡化的，它打算很快地表達出企業的高階訊息，而不描述所有詳細的內容，或者擺太多的表示法(notation)而使讀者感到迷惑。如果你有大量的企業使用案例，你可以簡單的產生一些含有使用案例子集的圖型。

一個從企業參與者或企業工作者到使用案例的箭頭，表示此參與者或工作者會開始起動這個使用案例。在這個例子，此職員開始進行訂定產品價格。一個從企業使用案例到企業參與者的箭頭，表示組織開始跟企業參與者傳遞訊息。在這個例子，當「交付產品(Deliver Products)」 的工作流程發生，組織（在此案例中，是駕駛員）跟客戶溝通。

活動圖

活動圖是用圖型的方式，來塑造使用案例的工作流程模型。此圖表現出工作流程的步驟，工作流程中的決策點(decision points)，誰負責完成每個步驟，那個物件受到此工作流程的影響。

圖 3.3 顯示一個活動圖的範例，在這個範例裡，一個客戶接到一個有缺陷的產品，並要求退款。

Figure 3.3 Activity diagram

我們可解讀此圖的意思如下：由客戶寫信要求退款開始這個流程，客服員(customer service representative)檢視這封信，如果這份要求文件是錯的，客服員寫一封拒絕信寄給客戶，通知客戶他的要求被拒絕了。如果接受這份文件，在會計支付人員開了一張支票的同時，客服員也把文件歸檔。一旦這兩個步驟都完成，客服員就通知客戶，他的要求已經核准了。

讓我們來檢視圖型裡的表示法。首先是開始狀態(start state)，它位在圖左上方的一個實心小圓點，這個符號讓我們知道工作流程是從那裡開始的。
　

圖型中的圓角矩形叫做「活動」。一個「活動」只是工作流程中的一個步驟，它是企業工作者要執行的任務。注意到圖中被區分成三個垂直的區域，叫做「泳道(swimlanes)」，沿著「泳道」的最上面，我們可以看到「角色」名稱，「角色」執行在這個「泳道」裡的所有活動。

在「活動」裡面，你可以列出在這活動中所發生的動作(actions)。動作祗是活動中的一個步驟，例如，假如你有一個叫「產生採購單(create purchase order)」的活動，組成動作的步驟可能包括「取得供應商的名字和地址」、「填寫要下單的項目、價錢和數量」、「計算總數」、及「列印訂購單」。這些步驟都很小，以至於處於高階的企業活動圖狀態時，無法擁有自己的「活動」，但它們對流程可增添一些資訊。

這裡有四種型態的動作：

• 發生在剛進入一個活動的動作，我們用「entry」這字來標示。

• 發生在活動進行當中的動作，我們用「do」這字來標示。

• 發生在剛離開一個活動的動作，我們用「exit」這字來標示。

• 發生在一個特別事件產生時的動作，我們用「event」這字來標示。

連接活動的箭頭我們稱它為「轉換」(transitions)，「轉換」讓你知道一旦現在的活動完成後，那一個活動將被執行。

在這個例子，一旦職員完成檢核此項目的購買價格，他(或她)開始進行將那些價格加上 10% 的流程。

我們可以在「轉換」上加入「限制條件(guard conditions)」，以顯示何時轉換才會發生。把限制條件放置在「方括號」內，在這個例子，「寫一封拒絕信(create rejection letter)」 這個活動，祗有在【文件錯誤(missing documentation)】這個限制條件為真(true)時，才會執行。

這條橫棒我們叫它「同步(synchronizations)」，它讓我們知道有兩個以上的活動同時在進行。在同步的最上方顯示一個「分叉(fork)」，它控制工作流程分開成兩個支流。當兩個分開的活動都完成後，就會有一個叫「結合(join)」的同步發生。當結合後，工作流程恢復成祗有單一執行緒的控制。同步棒(Synchronization bars)可以是橫的，也可以是直的。在圖 3.3 的例子，客服員把文件歸檔的同時，會計支付人員開立退款支票，祗有這兩個活動都完成後，客服員才能通知客戶。

最後，正方型的符號表示物件，這些物件受到工作流程的影響，隨著工作流程的進行而改變狀態。在此例子，一個要求可能是新產生的(new)、遭受拒絕的(denied)、或可接受的(accepted)。虛線是用來表示那個活動影響此物件的狀態，例如，產生一封拒絕信，使得把要求的狀態設成「拒絕」。

企業實體

一個企業實體是一個物件，在商業過程中，組織用來管理他的商務或產品。如其名稱所暗示的，企業實體就是企業在使用的實體東西。實體包括企業工作者每天在處理的事，例如可能是售貨單、帳目、運送盒、契約、小藍色圖釘---凡是與企業有關的東西。

仔細看最後的陳述，你應該列出公司主要交易的項目。假如你的公司是在製造圖釘，那小藍色圖釘的確是正確的企業實體，如果不是，那它就不值得關注。要問些問題如：

公司生產什麼產品？

公司提供什麼服務？

什麼項目是公司購買來執行工作的？

什麼項目是交付客戶或從客戶那裡接收過來？

什麼項目是從一個企業工作者傳給另一個企業工作者？

另外的竅門是，著眼於那些你己經定義的企業使用案例名詞，對大多數來講，每一個名詞就是一個企業實體。我們用下面的圖示來表示企業實體：

你可以添加屬性來詳述企業實體，一個屬性還算得上是用來描述這些實體的資訊，例如，一個叫「帳戶」的實體可能有些屬性，如：帳戶號碼(account number)、帳戶型態(account type；支票帳戶或儲蓄帳戶)、結餘(balance)、開戶日期(date opened)、結清日期(date closed)、及現況(status)。

如果你必需為企業實體定義屬性，你可陳列在實體名稱下面，顯示如下：

組織單位

一個「組織單位」只不過是企業工作者、企業實體、或其企業塑模元素的集合，它是一種用來組織企業塑模的機制(mechanism)。

許多公司是用部門、小組、單位來組成的，它們每一個都可以塑造成一個「組織單位」。「組織單位」包含在此部門、小組、或單位的所有企業工作者。在 UML，用下面的圖示來表示：