早期筆者有學過UML，用UML來分析一套系統，後來工作很少用UML，大部分用口述居多，只有盤流程的時候，用了幾款圖跟使用者和同仁確認，這次重新複習UML這一項，未來真有可能進化成專案負責人身兼帶人，會派上用場。
為何選擇UML，因為UML在使用者或是在跟IT可以非常用來溝通的利器，再來UML做需求分析UML學習門檻會降低，能用的圖那幾款就綽綽有餘了，UML分析管理專案實務是由對岸知名UML實戰派張傳波所著作，它專門用在UML進行捕捉需求分析方式，先前除了看邱郁惠在UML需求分析應用，張傳波也是我之前長期關注的人。
類別圖的建模注意事項
- 需求階段的建模與設計階段的建模式不一樣，需求建模是針對業務和需求提煉
- 優秀需求建模是設計建模良好的開始，但優秀設計建模還需考慮更多設計問題，不是能把業務模型轉換成設計模型來解決問題
- 有開發經驗的容易受到物件導向和程式設計容易進入實作來分析問題，這部分要先忘記
什麼是類別?
- 需求中提到各種業務概念、人物，經過抽象後可以視為類別
- 將某類別東西歸納再一起，也可以稱呼為類別
註記：類別有多種提煉角度，依據系統的目標、場景、選取合適的角度對事物進行歸納。
上面就是類別名字，中間屬性，最下面為操作。
實際上需求分析的時候不用管是public或是private，全部畫成public，操作部分在進行業務建模的時候不需要標示出來
類別圖用來獲得需求步驟如下：
- 識別出類別
- 識別出屬性
- 描繪出類別之間關係
- 對各種進行分析、抽象、整理
例子：若是開發一套教育管理系統，請用類別圖識別出教室有什麼樣的人? 這些人有什麼關鍵屬性?
從教育系統來看，類別如果是分析男人女人，沒有意義，如果屬性是身高、體重、這些屬性對教育系統沒什麼價值，思考識別出來的類別屬性，能幫助你判斷這個類別是否合適。
每個類別應具備它和新特點的關鍵屬性，一般無特別意義的屬性，不必要標記進去。
自己練習舉例一下，若是飲料店人員管理系統有哪些人? 這些人有什麼樣關鍵屬性?
筆者以生活例子來做練習，因為一家飲料店的人員，員工可能會外出送飲料，店長也有可能，因為店員辭職，跳下來做兼職，店長也有它的管理和行銷、經商的專長。
類別關係
以下是從生活當中來做舉例，從生活當中切入學類別圖，是可以累積自己在建模的能力，標註關係只有合適和不合適，沒有絕對答案。
兩個類別當中關係直線相連標註，上圖就是1對1關聯，因為老公只能有一個老婆，那當然如果你不介意的話，可以標註多個老婆狀況，只是你老婆會很不爽，你會天天被老婆吵吵鬧鬧。
上圖就是平常自己若是去外面進修上技術課程，一堂課只會有一個講師，那講師就會有底下有很多學員，上述就是1對多的屬性表示法。
上圖就是就是請假單底下有可能有0到多個，因為請假單我可能請事假事假不需要附件，病假或喪假當然我可能要提供一些證明，上圖的關係就是1對0到3個，我表示最多可以提供3個附件。
上圖就是意思就是角色關係，因為在組織結構，會遇到一個狀況，有一個部門是主管，然後專門督導底下的人，督導分部的人，屬性會以主管跟下屬的關係來做表示。
上圖就是意思就是依賴，請假單的會是列名是誰請的假，可以透過假單來找到請假者。
上圖就是意思就是在UML術語來說是泛化，但其實比較老土的是繼承，可以了解為抽象和提煉等。
最後就是談合成和聚合關係，我的記法是表示有分為空心和實心的菱形表示法，空心的部分顯得較虛弱，實心比較強壯。
要點
- 空心的部分在上圖表示如果部門沒有了，員工可以繼續存在
- 實心的部分，當部門沒有了，員工也就不存在
老E隨手寫
