1.前言
對于當前社會背景下從事軟體開發的作業者而言，“寫代碼”實際上并不是唯一的作業，特別在一些中小型的企業當中，這些企業往往對于開發者的要求，不單單停留在寫代碼完成相應功能上，在實際的軟體專案作業開展期間，企業往往會節省成本需要你“身兼多職”，
基于這種市場現象而言，我對當下社會作為一個合格軟體開發者的定義，更偏向另一種稱謂：即“問題解決者”，解決以業務軟體為中心的各式各樣的問題，所以在編碼作業之外還會參與：需求分析、專案設計、測驗、專案部署等作業，除了參與多方面職能的作業之外，還需要你會多項技能，其中主要包括：制作檔案、畫圖（UML建模）、溝通技巧，甚至還需要你會PS，（P過圖的程式員請留言）
以下是你作為軟體開發者可能會撰寫的檔案，檔案其中會包含著大量各式各樣用UML繪制的模型圖：
在軟體領域的眾多作業中，使用畫圖（UML建模）是最為基本、關鍵的技能，UML繪制建立的模型圖，不僅會作為我們在開發前期與客戶協商確定的“藍本”，還會是團隊內部敲定方案的“參照物”，還會是軟體開發的“依據”，還會是制作各類檔案的關鍵元素，從這樣來看，畫圖（UML建模）涉及軟體開發的方方面面，并貫穿整個軟體生產的生命周期，
所以對于UML建模在軟體作業中的地位可見一斑，并且在結合當下市場的作業環境，我認為“不會畫圖的程式員，不是一個合格的程式員”，綜上所述，我打算圍繞UML建模這門手藝開展系統性的介紹，本篇將先理論概念作為開端，促使你對UML的認識有所覺悟，在順帶提一句，你知道什么是“軟體危機”嗎？
2.設計的重要性
早些年剛接觸編程的王小菜，收到的第一個任務是實作某管理系統的登錄模塊，自信滿滿的他為了展現自己的實力，第一時間就是打開IDE進行編碼，并在一天內迅速的完成了任務，然而在交付演示的程序中，專案經理發現除了常規的登錄和注冊之外，登錄模塊還又很多功能沒有完善，例如：登錄安全的措施、忘記密碼的措施、身份驗證機制、單點登錄的實作等等，這些缺失考慮的功能，導致王小菜一次又一次的進行返工，從原本預計一天內完成的登錄模塊，卻足足花費了他一周的時間，他還時常加班修復一些Bug，
通過上面的事例，你是否也曾發現過“王小菜”的身影，對于大多數剛從事軟體開發的從業者而言，在實際的作業中，在一開始接收到需求或開發任務后，就利馬直接開始上手寫代碼，深怕難以體現自己的開發效率，對于開發的功能是想到哪一塊就寫到哪一塊，毫無規劃可言，
其實軟體的制作就是一種工程，和我們建筑高樓大廈是一樣的道理，所以在制作前必須進行合理的設計，并對軟體進行建模和管理，不能一上來就開始盲目的寫代碼，對于任何業務需求、功能設計必須先分析、規劃之后才能開始編碼，在寫代碼事情必須明白：要做什么？做成什么樣？怎么去做？
為了避免這種“先斬后奏”的開發方式，我們必須在編碼之前通過UML進行建模用于分析和設計，只有經過合理規劃和設計，才能最大程度上減少，客戶一而再再而三的返工要求，或是頻繁的變動需求，
3.模型
在介紹UML之前，我們必須先理解什么是模型，理解模型的概念是理解UML建模的基礎，
模型從概念上描述：它是通過形象化的手段，對現實世界事物簡化描述的一種方式，簡單來概括，模型是對現實時間的簡化，為什么使用模型？因為通常某些復雜的事物或軟體系統，在描述和實作上是非常復雜的，在事物或軟體完成之前，通過文字我們不可能將這些事物理解清楚，所以通過使用模型可以對復雜的事物進行抽象化、形象化，以便我們可以更好的理解、更好的進行分析設計作業，
這個道理可以通過現實生活中的一個場景形象的類比，那就是我們購房的例子，在當下的社會背景下，我們大多數人購買新房的時候，新房往往都還沒有建造出來，開發商為了讓消費者提前買到房，它們往往會在售樓部搭建各式各樣的房屋沙盤模型，其中有室外的、室內的、全景的，以便消費者能在房屋沒有建造完成之前，就能夠感受房屋最終建造的效果，除此之外，在生活中使用模型來形象化描述現實世界事物的方式比比皆是，你可以想到有哪些？
結合上面的例子和概念，在軟體工程中也是同理的，我們為了讓客戶能夠直觀的理解軟體的構思、為了軟體能夠更好的分析和設計、為了開發人員能夠更好的實作軟體功能，所以我們會根據業務需求并結合面向物件的分析與設計思想（OOA/D），將軟體工程中不同階段、不同場景，通過UML來繪制建立模型，所以，通過UML建模可以將我們對軟體的構思、設計、概念以一種圖形化的方式表達出來，
使用UML建模可以為我們構建軟體專案帶來很大好處，但是使用UML有時并不是必須的，這也要取決于軟體專案的規模和體量，通常我們構建企業中大型的資訊管理軟體，其中存在復雜的業務場景，所以我們必須使用UML建模，但是如果面對的軟體體量很小，沒有什么業務，我們可以選擇簡化或省略UML建模，所以UML的重要程度是取決于軟體專案規模決定的，規模越大UML建模的重要性越大，反之越小，
4.簡介
早在20世紀90年代就出現了UML，由于其簡單、統一，又能夠表達軟體設計中的動態資訊和靜態資訊，目前已經成為可視化建模語言事實上的工業標準，這就相當于你吃中餐默認的餐具是筷子，而軟體建模就默認使用UML，其地位不言而喻，
UML簡稱可以翻譯為兩種形式：1.UML（You Must Learn）、2.UML（Unified Modeling Languang），第一種是從其重要程度巧譯而成的“你必須學”，第二種則是官方的定義“統一建模語言”，UML是物件管理組織（OMG）指定的一個通用的、可視化的建模語言標準，它可以用來：可視化、描述、構造和檔案化軟體專案中的各種單元（業務、功能、演算法、流程等等），
UML并不像我們的編程語言那樣五花八門，UML在建模語言中是統一的，就是說不同領域、不同技術堆疊使用的建模語言大多數都是UML，因為UML是從所有軟體建模語言的基礎上提煉的精華，幾集百家之所長，它是軟體建模語言的集大成者，UML還突破了軟體的限制，廣泛吸收了其他領域的建模方法，不僅可以用于軟體領域的建模，還可以用于其他領域的建模作業，由此可見，UML是一種統一化極具廣泛性的軟體建模語言，
5.結語
UML從理論上其實可以“羅里吧嗦”的引出很多概念性的東西，對于理解UML這些概念而言，我們覺得其中最為重要的是，通過這些概念喚醒你的覺悟，深刻去體會軟體設計的重要性，不要需求任務一來就立馬上手開始寫代碼，我們需要思考和分析，懂得設計和分析的人大多數都會有一個感觸：在做一個專案或一個需求時，如果有良好的設計，其實編碼的作業量放到整個軟體生命周期上不會超過一半，
對于UML的知識體系來說其實可以單獨作為一門學科的，是屬于軟體設計范疇的，當然作為軟體開發者不可能花費太多精力，將UML所有細節都了然于心，我們應當遵循“二八定律”根據日常作業中經常使用的部分進行深入即可，我個人覺得對于UML學習比較重要的幾點如下：
- 能夠從不同的視角、維度繪制不同的圖形，
- 能夠清楚知道在軟體專案的不同階段繪制什么型別的圖，
- 能夠根據面向的用戶繪制不同層次的圖形，也就是能夠把握圖形呈現的抽象程度，
- 能夠根據業務需求和設計思想繪制常用的圖形，其中包括但不限：類圖、用例圖、活動圖等，
文章主要作為UML系列的開篇主要以理論為主，在后續的UML系列文章中，我主要從實踐操作性出發，介紹如何具體繪制軟體開發中常用的模型，我相信只有在實踐中才能更好的掌握UML建模的能力，
知識改變命運轉載請註明出處，本文鏈接：https://www.uj5u.com/gongcheng/502760.html
標籤：其他
上一篇：你必須學UML之理論篇