考勤系統的業務概念圖

業務概念圖是大家比較容易了解的說法，不少資料上提到的領域模型（Domain Model），你可以了解為業務概念模型。 我們課程盡量不使用大家難懂的詞彙，下面我們繼續以業務概念圖來表達。 整理出系統的業務概念，我覺得是多個步驟中，最難也是最重要的步驟。 說它難，是因為： 1.并不是誰都能準确全面地識别出業務概念的。 2.要準确描繪這些概念的關系就更加難。 3.對這些業務概念進行提煉，是難上加難！ 說它重要，是因為： 1.這是準确需求了解的基礎。 2.這是資料庫設計、實體類設計的輸入。

在我們公司，盡管《需求規格說明書》中有“業務概念圖”的章節，但很多項目經理都不能畫好，很多複雜的系統隻能畫出非常簡單的幾個業務概念。能否做好其實很依賴于你的功力！

你可能會問：有些公司不用UML，不用類圖的，難道他們就不能表達好業務概念？

那當然不是了，類圖隻是其中一種表達方式，一些公司會通過資料字典或者是詳細的文字和表格來說明各種業務概念，不過我推崇的還是使用類圖，類圖強在友善表達類之間的關系和友善進行提煉！

回到這個考勤系統，考勤系統有什麼業務概念、它們之間是怎樣的關系呢？

我們強調了業務概念圖這麼高的難度，你可不要被吓怕了，越難的東西你掌握了你就約值錢！

請你盡你所能畫出本系統的業務概念圖，完成後才繼續往下學習噢！

這是一個考勤管理系統，與考勤相關的重要業務概念有：考勤記錄、請假記錄、外出工作記錄。

這個系統涉及到人和部門，故重要業務概念還有：部門、員工。

本圖列出了關鍵的業務概念、業務概念的重要屬性、業務概念之間的關系，相關業務規則通過注釋來說明。

大家所在的公司情況不一樣，大家對考勤的了解角度不一樣，這個圖就會不太一樣。

請你比較你畫的圖與上圖的差異，線上提出你的問題，講師将會解答大家的疑問！

考勤記錄：

其實就是打卡記錄。大家去打卡的時候，有想過打卡機記錄了什麼嗎？打卡機記錄了你的工卡的ID和打卡時間。

打卡機如何知道這是上班打卡還是下班打卡？其實它是不知道的，隻能看時間與打卡順序。

如：你們上午上班時間是9:00-12:00，但打卡機有一條記錄顯示打卡時間是10:30，請問這算上班打卡還是下班打卡？

光靠這些資訊還不能判斷，如果這是該ID當天的第一次打卡，應該算上班記錄，如果是第二次打卡，則可能是下班打卡或者是外出工作時的打卡。

我們公司以前中午休息，大家是需要打卡的，下班時打一次，上班時再打一次，這樣一天要打4次卡。中午要打卡的規定，導緻了很多問題，大家中午很容易忘記打卡，這樣就導緻一個人一天隻有2次或者3次的打卡記錄，導緻了一些管理上的混亂。後來我們取消掉中午打卡的規定，隻需要上午上班和下午下班各打一次卡便可。

你思考這個考勤系統的時候，如何也遇到我們公司類似的中午打卡問題咋辦？那就應該先做業務重組，用簡單有效的辦法來管理打卡。

你可能有這個問題：打卡機不是記錄了員工的工卡ID和打卡時間嗎？為什麼考勤記錄這個類沒有工卡ID這個屬性？

這個問題問得好！

考勤記錄與員工這兩個類之間是有關系的，我們看到一個員工有多次打卡記錄，一次打卡記錄隻對應一個員工。也就說說這樣的對應關系，已經反應了通過考勤記錄是能找到相應的員工的，故考勤記錄中不需要設工卡ID座位屬性。

類似的，請假記錄、外出工作記錄類都沒有“員工ID”之類的屬性，繪制業務概念圖時，我們不需要在類中展現它們的“外鍵”，事實上“員工ID”之類的屬性，是這些業務類關系的實作方式之一而已，在需求階段我們不需要也不應該明确這些關系的實作，何況實作方式還有其它可能呢！

請假記錄：

隻有開始時間與結束時間兩個屬性，你可能會問請假時長為什麼不做為屬性之一？

請假時長可以由開始時間與結束時間計算出來，這是一個“導出屬性”，對于這樣的情況，一般不需要在類中再加一個屬性，概念圖的類的屬性，最好都是“原始”屬性，不能由其它東西推導出來的。

當然到資料庫設計、程式設計時，這些“導出屬性”有可能會設計為資料庫的字段和類的某個屬性，但這是實作方式，繪制概念圖時不需要也不應該明确這些内容。

請假是分類别的，類别沒有直接放到請假記錄的屬性中，而是抽離出來。

請假類别是很重要的一個東西，不同的類别請假的流程、薪金減扣計算都不太一樣，對于重要的類别，我一般會單獨一個類來表示，并通過批注說明具體有什麼類别。

這些類别，在資料庫設計時往往被設計為單獨的一個表，在程式中往往會使用枚舉來表示。将這些重要類别單獨一個類表示，可友善設計人員思考。

外出請假工作記錄：

在思考這個類時，其實是有一些業務上的麻煩的。不知道大家外出工作流程是怎樣的？

我們需要外出者填寫外出申請，标明起止時間和工作内容等，同時要求如果需要外出時你在公司，則你還需要打卡才能外出。

我們之前還曾很“無聊”地規定所有銷售人員，就算你當天一整天都要外出，你都需要先到公司打卡，當然我們後來取消這個不人性化的規定了。

不過現在還是存在問題，也就是很多情況下的外出工作，即需要填寫外出申請，也需要打卡，也就是要求：外出工作記錄與考勤情況應該是一緻的，也就是外出工作記錄類的注釋所寫的内容了。這樣的要求有一定的管理麻煩，但暫時又想不出更簡單有效的管理辦法，這就意味着我們的考勤系統需要考慮這樣的功能：能友善檢查外出工作記錄與考勤情況有沒有出入。

整理業務概念時，你會有很多思考。考勤系統看上去不複雜，但涉及到每一個人的利益，涉及到公司的管理制度，就不是這麼簡單了。

當你去做一個業務系統需求分析時，你的工作重點其實是幫助客戶重組業務流程，不使用系統手工操作時，很多工作是不嚴格和随意的，不整改這些工作，系統是無法做出來的。

重組業務是高難度的工作，你現在才重組了業務概念部分，準備下一個挑戰吧，重組業務流程！

本文轉自左正部落格園部落格，原文連結：http://www.cnblogs.com/soundcode/archive/2011/07/21/2112656.html，如需轉載請自行聯系原作者