1. 首頁 > 生活 > >

面向對象的照妖鏡——UML類圖繪制指南

生活百科

1.前言感受
在剛接觸軟件開發工作的時候，每次接到新需求，在分析需求后的第一件事情，就是火急火燎的打開數據庫（DBMS），開始進行數據表的創建工作 。然而這種方式，總是會讓我在編碼過程中出現實體類設計疏漏的地方，導致我在寫業務代碼時，還回頭去反復的修改數據表和實體類 。為了規避這樣的情況，我學習期間發現了UML中關于類圖的知識點，它讓我知道，作為編碼者在分析需求后，做的第一件最基本的事情應該是進行面向對象分析，然后使用UML繪制類圖的方式進行面向對象的設計 。在類圖繪制完之后，使用類圖與組員溝通設計思想，分析設計的可行性，在項目組一致達成共識后才進入后面的動手環節 。
以上這種，通過面向對象分析和設計來繪制類圖的工作習慣，我一直延續至今 。因為，它不僅能保證軟件構建的穩定性，還能提升我們面向對象的思想和實踐能力 。在實際中，極少數的情況下，公司會聘用專門的設計人員為你提供設計方案，更多的情況是，程序員要擔任設計和編碼的綜合性工作，所以我認為掌握UML類圖，是一名程序員的技能標配 。
三個層次
在標準的軟件工程建模當中，類圖實際上根據三個層次劃分為了三種類型的類圖，根據使用順序分別為：概念層類圖、說明層類圖和實現層類圖 。概念層用于業務建模階段，著重于對問題領域的概念化理解；說明層用于概念模型階段，主要考察類的交互涉及哪些接口；實現層用于設計階段，主要考慮類在代碼技術層面的實現細節 。本文主要主要以實現層的類圖為主，因為實現層的類圖是最常用的，并且它是直接影響到我們實際的編碼工作的，下面我會針對它涉及的繪制方式、類之間的關系展開詳細講解 。
2.類的識別UML類圖的基本語法是很簡單的，可能懂點編程的人在不系統學習的情況下，借助繪圖工具都可以繪制出來 。但在實際的業務需求中，充斥著各種晦澀的業務概念、事物，要從其中準確無誤的提煉出有利于業務系統的類，并非一件簡單的事情 。
對于類的識別，并沒有很具體的步驟、公式進行照搬硬套，往往只能通過自身的經驗和面向對象的造詣去識別類 。并且識別類往往也不是一蹴而就的，還要結合類與類之間的關系、業務的使用場景，反復推敲，才能逐步得到合適的類型 。對此我只能提供一些概念性的經驗心得，讀者可以選擇性的參考，并不作為一個標準 。
類的識別很大程度上需要依靠“邊界”，這是一個復雜的概念，你可以簡單理解它相當于一個范圍，設定邊界可以讓我們知道能做什么事情，和不能做什么事情 。并且邊界的設定會決定我們看待事物的視角和抽象事物的層次 。對于類的識別而言，其邊界可參考當前的系統的目標、業務場景等，有了清晰的邊界，可以縮小類的識別范圍，不在是天馬行空，毫無根據 。
如果不通過邊界確定一個角度，那么對于同一事物，通過不同的角度會提煉出不同的類型 。就拿我們自身舉例，從職業的角度來看我們則是程序員，從國家的角度來看我們則是中國人，從動物的角度來看我們則是人類 。所以我們必須要通過邊界來確定一個角度，從而清晰的分析獲取有利于業務系統的類型 。

面向對象的照妖鏡——UML類圖繪制指南

文章插圖
例如，你需要在一個網課教育系統中，分析上課的場景中會有哪些類型 。如果你不考慮邊界（網課教育系統中的上課場景），那么你可能天馬行空的分析出：男人、女人這些類型 。這樣分析出的類型和屬性顯然對系統毫無意義，也無法為業務提供價值 。如果你考慮到了邊界（網課教育系統中的上課場景），那么你分析出的類型必然是在這個邊界內有利于業務的：老師、學生 。

經驗總結擴展閱讀