簡介一套圍繞《UML基礎(chǔ)、建模與設(shè)計實戰(zhàn)》的課件與工程實例資料包面向UML初學(xué)者、軟件工程專業(yè)學(xué)生及需要做系統(tǒng)建模設(shè)計的開發(fā)人員旨在通過講解和案例將UML理論落到實際項目中。壓縮包共45個文件含13份PPT課件、12個UML工程文件、14個Java示例總大小僅4.63MB輕量易下載課件按章節(jié)覆蓋UML概述、面向?qū)ο?、用例圖、類圖、順序圖/協(xié)作圖、狀態(tài)圖/活動圖、組件圖/部署圖及RUP等核心內(nèi)容工程案例則包括汽車租賃系統(tǒng)、圖書管理系統(tǒng)、BBS論壇、新聞管理系統(tǒng)、數(shù)碼錄音機等既有靜態(tài)結(jié)構(gòu)建模也有動態(tài)行為設(shè)計便于對照學(xué)習(xí)。目前已有481人學(xué)習(xí)瀏覽。這份資料既能作為課堂同步講義也能用于課后自學(xué)和課程設(shè)計參考通過研讀PPT并打開對應(yīng)Java與UML文件可以快速掌握各類圖的繪制方法及UML在軟件開發(fā)全流程中的實際用法。 UML這東西你要是問剛?cè)胄械某绦騿T十個有八個會說“就是畫圖嘛”。但你真要他畫一張類圖出來他可能連繼承箭頭朝哪邊都記不準。我做《UML基礎(chǔ)、建模與設(shè)計實戰(zhàn)》這套課件和配套例子就是沖著這個痛點去的——不是把UML語法從頭到尾念一遍而是帶著你把需求拆成用例、把用例變成類圖、把類圖落成代碼走完一個完整的建模設(shè)計閉環(huán)。這套材料最適合三類人一是軟件工程專業(yè)的在校學(xué)生要應(yīng)付考試又要動手做課設(shè)二是剛?cè)肼毜捻椖啃氯思瓤床欢畧F隊里的架構(gòu)圖自己也不會畫設(shè)計圖三是想系統(tǒng)補建模能力的開發(fā)人員雖然寫過不少業(yè)務(wù)代碼但畫出來的類圖總被架構(gòu)師吐槽。1. 先搞清楚UML到底解決什么問題1.1 很多人把UML當(dāng)成“畫圖”其實它是一套溝通協(xié)議這是一個特別常見的誤區(qū)。UML全稱Unified Modeling Language統(tǒng)一建模語言。注意“語言”這兩個字它跟英語、Java是一個性質(zhì)的東西核心作用是溝通。只不過它的溝通對象是軟件參與者——產(chǎn)品經(jīng)理、架構(gòu)師、開發(fā)、測試甚至客戶。你畫一張用例圖產(chǎn)品經(jīng)理能看懂畫一張類圖開發(fā)能對接畫一張部署圖運維知道怎么上線。UML強調(diào)“統(tǒng)一”就是因為大家都得按同一套符號規(guī)則來否則你畫的圓我不認識我畫的箭頭你理解成另一個意思溝通成本不降反升。我見過不少項目團隊說是用UML實際就是拿畫圖工具隨手畫個大概樣子箭頭隨便用矩形大小不齊標簽愛寫不寫。這種圖發(fā)到群里每個人理解都不一樣最后代碼寫出來跟圖完全是兩回事。UML的價值不在于圖好不好看而在于信息傳遞的準確性。一個空心三角箭頭和實心三角箭頭語義差著十萬八千里畫錯了會直接影響整個團隊對設(shè)計的判斷。所以學(xué)UML的第一個門檻不是記住多少個圖而是建立“符號即語義”的嚴謹感。1.2 這套課件覆蓋的三大板塊課件標題分三段基礎(chǔ)、建模、設(shè)計實戰(zhàn)。三個詞對應(yīng)三個層次缺一不可?；A(chǔ)部分把UML中最常用的幾種圖講清楚包括類圖、用例圖、時序圖、狀態(tài)圖、活動圖、組件圖、部署圖。這里只講語法和元素不牽扯復(fù)雜的項目背景目的是讓人先把“詞和句法”混個臉熟。這個階段我刻意把例子做得小而具體比如用“一個學(xué)生選課”來演示類圖的多重性用“訂單發(fā)貨”來演示狀態(tài)圖的狀態(tài)遷移。小例子覆蓋面廣學(xué)起來輕松也方便后面串成大項目。建模部分講怎么從需求分析出發(fā)把一段描述性的業(yè)務(wù)文字轉(zhuǎn)化成UML模型。這是很多教材容易忽略的地方——考試讓你畫一張類圖你畫得出來丟給你一份幾十頁的需求文檔你直接就懵了。建模就是解決“原材料怎么加工”的問題它比單純畫圖難得多因為涉及抽象、分類和取舍也是拉開普通開發(fā)者和架構(gòu)師差距的關(guān)鍵。設(shè)計實戰(zhàn)部分用完整的項目案例把前面積累的知識點串起來從需求梳理、用例分析、概念建模到詳細設(shè)計全流程走一遍。這一部分強調(diào)“取舍能力”哪些類該抽出來哪些關(guān)系該建哪些細節(jié)可以留到代碼里再說。我個人覺得這是整套課件的精華前兩部分是“學(xué)”第三部分是“用”只有真的跟完一個完整案例你才會對UML產(chǎn)生手感。2. 課件和例子的設(shè)計思路案例貫穿語法隨用隨講2.1 為什么不用“一章一種圖”的傳統(tǒng)寫法傳統(tǒng)教材喜歡把UML每種圖單獨列一章類圖一章、用例圖一章、時序圖一章、狀態(tài)圖一章每章講完語法再配幾個孤立小例子。這種結(jié)構(gòu)適合當(dāng)字典查閱但不適合第一次學(xué)。問題在于真實建模中這幾種圖是交叉使用的。你不可能先把所有用例圖畫完再想類圖而是用例分析到一半概念類就浮現(xiàn)出來了類關(guān)系定到一半又要用時序圖驗證消息流轉(zhuǎn)是否順暢。所以課件采用了“案例貫穿、語法隨用隨講”的思路。每引入一種新圖就掛靠到同一個案例鏈路的某個環(huán)節(jié)上讓讀者直觀感受到“這種圖在這個場景出現(xiàn)了它解決的是那個問題”。這種講法第一次讀可能會讓人覺得有點跳——怎么一會兒類圖一會兒時序圖——但堅持學(xué)到中后段前面的知識點會自然串起來產(chǎn)生一種“原來如此”的頓悟。課件里我也明確建議第一遍通讀不要停下來摳細節(jié)第二遍再按章節(jié)精讀語法。2.2 例子怎么選貼近生活又帶設(shè)計含量選例子是門手藝活。太簡單的例子比如“學(xué)生選課”一張圖就畫完了學(xué)不到東西太復(fù)雜的例子比如“電商中臺系統(tǒng)”信息量巨大新手看到一堆類直接勸退。課件里我選了三個例子來承載不同階段的內(nèi)容。第一個是圖書借閱系統(tǒng)用于基礎(chǔ)篇。它貼近校園生活領(lǐng)域概念清晰實體關(guān)系不超過6個類適合講類圖基本語法和對象圖畫法。第二個是訂單管理系統(tǒng)用于建模篇。它引入訂單狀態(tài)流轉(zhuǎn)待支付、已支付、已發(fā)貨、已完成、服務(wù)層接口設(shè)計這些真實項目要素能講清楚用例圖、活動圖、時序圖怎么配合。第三個是支付網(wǎng)關(guān)對接用于設(shè)計實戰(zhàn)。這個案例有“技術(shù)含量”因為涉及策略模式——支付寶、微信、銀聯(lián)這些不同支付渠道被抽象成統(tǒng)一的支付策略接口讓新手直觀看到設(shè)計模式在UML圖里是怎么表達的還能引出“開閉原則”對擴展開放、對修改關(guān)閉這類設(shè)計思想。三個案例的共同點是“有真實感但不過度復(fù)雜”每一階段學(xué)完都能獨立畫出一組圖成就感來得很快也方便讀者在練習(xí)時對照自己的生活經(jīng)驗理解業(yè)務(wù)。3. 核心知識點拆解這些細節(jié)是新手必過的坎3.1 類圖關(guān)系的箭頭含義對照表類圖是UML里出現(xiàn)頻率最高的圖但對新手而言最頭疼的就是那一堆箭頭。說實話考試畫錯箭頭頂多扣兩分工作里類圖畫錯箭頭評審會上就是公開處刑。下面這張表我建議直接抄走貼在工位旁邊關(guān)系類型圖形表示方向語義說明代碼對應(yīng)繼承/泛化空心三角實線子類指向父類“is-a”關(guān)系子類擁有父類的能力extends實現(xiàn)空心三角虛線類指向接口類實現(xiàn)接口中定義的方法implements依賴普通箭頭虛線使用方指向被使用方某個方法參數(shù)、返回類型或局部變量用到對方方法局部變量、方法參數(shù)關(guān)聯(lián)普通箭頭實線按需標注方向類持有對方的引用穩(wěn)定的“has-a”關(guān)系成員變量聚合空心菱形實線菱形端指向整體整體與局部可分離局部生命周期獨立構(gòu)造注入、setter注入組合實心菱形實線菱形端指向整體整體與局部同生命周期局部沒有獨立意義類內(nèi)部創(chuàng)建成員變量特別注意后三行的區(qū)別。依賴是最弱的關(guān)系強調(diào)的是“方法層面碰了一下”關(guān)聯(lián)是相對穩(wěn)定的持有聚合和組合都屬于“整體-部分”區(qū)別在于生命周期是否綁定。教你一個生活化記法一輛汽車和它的發(fā)動機是組合發(fā)動機拆了車就不能開兩者生命周期強綁定一個教室和里面的椅子是聚合椅子搬走了教室照樣存在生命周期互相獨立。3.2 用例圖不是畫幾個圈就完事用例圖看起來最簡單——小人和橢圓新手半小時就能畫一張。但真正難的是“用例粒度”的把握。一個“用戶登錄”是畫成一個用例還是拆成“密碼登錄”“短信驗證碼登錄”“掃碼登錄”三個用例這沒有絕對標準取決于你想表達的業(yè)務(wù)層級。課件里給了一個判斷原則如果這個用例能讓參與者感知到一個完整的業(yè)務(wù)價值閉環(huán)那就夠“粗”如果只是業(yè)務(wù)流程中的某個步驟那應(yīng)該降級成子流程或者放到活動圖里當(dāng)一個節(jié)點。用例之間的關(guān)系也是高頻考點。include包含表示“主用例執(zhí)行過程中一定會調(diào)用的子功能”比如“下訂單”包含“庫存查詢”extend擴展表示“在特定條件下才會觸發(fā)的可選項”比如“下訂單”擴展“使用優(yōu)惠券”。一個代表必然發(fā)生一個代表可能發(fā)生這個區(qū)別是最容易考到、也最容易混淆的知識點。在畫圖時include和extend都使用虛線箭頭區(qū)別在箭頭指向include是被包含用例放在執(zhí)行方extend是擴展用例指向主用例。3.3 時序圖和狀態(tài)圖的適用場景怎么分這兩個圖常被初學(xué)者當(dāng)成同一個東西其實關(guān)注點完全不一樣。時序圖關(guān)注“多個對象之間消息的時間順序”解決的是“誰調(diào)誰、什么時候調(diào)、按什么順序調(diào)”狀態(tài)圖關(guān)注“單個對象在其生命周期內(nèi)狀態(tài)的變遷”解決的是“這個對象在什么條件下變成什么狀態(tài)”。用一個例子秒懂。一個訂單對象有“待支付”“已支付”“已發(fā)貨”“已完成”這些狀態(tài)以及“支付成功”“發(fā)貨”“確認收貨”這些觸發(fā)遷移的事件這就是狀態(tài)機圖的主場。而用戶點擊“提交訂單”之后OrderService要調(diào)用StockService扣庫存、調(diào)用PaymentService生成支付單、再調(diào)用MessageService給管理員發(fā)通知這個調(diào)用順序和消息內(nèi)容就是時序圖的主場。建模的功力很大程度上體現(xiàn)在“選對圖”這件事上。選對了一張圖頂千行文檔選錯了畫得再漂亮也是在繞遠路。4. 從建模到寫代碼把圖翻譯成實現(xiàn)的路子4.1 建模的三個層次缺一不可很多初學(xué)者把建模理解成“畫一張能看懂的圖”但實際工程中的建模有三個層次不同階段關(guān)注的內(nèi)容完全不同。概念層建模最貼近業(yè)務(wù)。這個階段不涉及任何技術(shù)棧只關(guān)注業(yè)務(wù)領(lǐng)域里的實體、規(guī)則和關(guān)系。比如“讀者可以借閱多本圖書但同一本書最多借兩周”畫出來的類圖只有業(yè)務(wù)名詞和關(guān)鍵關(guān)系不寫方法、不寫字段類型連屬性可見性都不用標。規(guī)格層建模開始考慮軟件系統(tǒng)了類的屬性、方法、可見性、關(guān)系上的多重性都要明確寫出來。同一張讀者借書圖這個階段就會出現(xiàn)borrowDate、returnDate這些字段出現(xiàn)borrowBook()這樣的方法也要標出Reader和Book之間的1對多關(guān)系。實現(xiàn)層建模則要貼近具體代碼框架。比如用Spring要做三層架構(gòu)那類圖里就會出現(xiàn)Controller、Service、Mapper這些技術(shù)模塊甚至?xí)屑兗夹g(shù)類如BookMapper接口、BookService接口等。大多數(shù)教材只停在規(guī)格層課件把概念層和實現(xiàn)層補上就是為了說明一個道理同一個系統(tǒng)可以有多個UML模型它們描述的是不同視角沒有哪張圖是“唯一正確答案”關(guān)鍵是搞清楚當(dāng)前階段要解決什么問題。4.2 從用例到類圖的推導(dǎo)過程建模實操中新手最容易卡在“用例圖怎么變成類圖”。課件總結(jié)了三個樸素的方法找名詞、標動詞、分邊界。第一步找名詞把用例描述里的名詞圈出來比如“圖書”“訂單”“用戶”“借閱記錄”這些大概率就是候選類。第二步標動詞動詞短語往往對應(yīng)類的方法或類之間的關(guān)聯(lián)比如“用戶提交訂單”“提交”是OrderService的方法“用戶”和“訂單”之間就產(chǎn)生了關(guān)聯(lián)。第三步分邊界有些名詞不適合做成類比如“身份證號”更適合作為User的一個屬性而不是單獨建一個IdCard類“微信支付配置”雖然能獨立成類但如果你只是在數(shù)據(jù)庫表里存幾行配置那做一個Config實體就夠了。這個過程不是一步到位的通常需要在用例圖和類圖之間來回迭代好幾輪。課件里特意保留了推導(dǎo)過程的修改痕跡截圖就是為了讓讀者看到建模本來就是一個不斷修正的過程第一稿不完美是正常的不可能拿著需求就能直接畫出滿分設(shè)計。4.3 讓模型不變成擺設(shè)很多開發(fā)者的真實狀態(tài)是項目啟動時辛辛苦苦畫了三五張UML圖一進編碼階段圖就再也沒更新過三個月后圖和代碼完全脫節(jié)圖淪為評審時的擺設(shè)。解決這個問題的思路是把UML圖當(dāng)成代碼的“注釋升級版”而不是代碼的“前置交付物”。具體操作上建議把圖納入版本管理跟代碼一樣提交到Git倉庫每次更新圖就留一個commit記錄。代碼評審的時候順手看一眼對應(yīng)的類圖有沒有同步更新?，F(xiàn)在不少工具支持從代碼反向生成UML類圖比如IntelliJ IDEA的Diagram功能、StarUML的代碼工程導(dǎo)入雖然不能做到代碼和模型全自動雙向同步但“小步同步、每次迭代都更新”至少能讓圖保持活力。課件最后一章專門講“怎么讓UML活下來”核心就一句話別把圖當(dāng)圣旨把圖當(dāng)溝通工具。5. 一個完整例子圖書借閱系統(tǒng)的建模實戰(zhàn)5.1 第一步從需求到用例圖用圖書借閱系統(tǒng)完整走一遍建模流程。先給一段需求描述“系統(tǒng)面向圖書館管理員和普通讀者。讀者可以檢索圖書、借閱圖書、歸還圖書、查看個人借閱記錄和欠款。管理員負責(zé)圖書的錄入、下架、讀者賬號管理以及處理借還和罰款業(yè)務(wù)?！毙枨蟛婚L但夠用了。先確定參與者讀者、管理員。然后畫用例圖讀者有檢索圖書、借閱圖書、歸還圖書、查看借閱記錄管理員有圖書錄入、圖書下架、借還處理、罰款處理。注意“讀者借閱圖書”和“管理員處理借還”從業(yè)務(wù)上看是同一個動作的兩個視角在用例圖中這很正常只要參與者區(qū)分開就行。另外“系統(tǒng)自動計算超期罰款”可以作為一個參與者是“時間觸發(fā)器”的用例初學(xué)階段容易漏掉這種非人類參與者。用例圖畫完別急著進入類圖。每個用例還要配有基本的用例描述主成功場景、異常分支、前置條件、后置條件。這些描述才是后續(xù)畫時序圖的原料。5.2 第二步識別類與關(guān)系畫出類圖基于用例描述開始找類。名詞有讀者、圖書、借閱記錄、罰款單、館藏副本動詞有借閱、歸還、繳納。這里遇到一個關(guān)鍵設(shè)計決策“圖書”和“館藏副本”要分還是合在需求“一本書可以有多本副本”出現(xiàn)時就必須拆成Book書目和BookCopy副本兩個類否則無法表達多本副本同時被不同讀者借出。繼續(xù)梳理關(guān)系Reader讀者和LoanRecord借閱記錄是一對多BookCopy和LoanRecord也是一對多LoanRecord同時關(guān)聯(lián)Reader和BookCopy。這里有一個值得思考的設(shè)計點借閱記錄應(yīng)該關(guān)聯(lián)到BookCopy而不是Book因為讀者實際借走的是具體的一本副本而不是書目。這種“為什么這樣建?！钡乃伎歼^程比最終圖本身更重要也是我想通過例子傳達的。5.3 第三步用時序圖驗證設(shè)計合理性類圖畫好不代表設(shè)計完成。我習(xí)慣畫一張時序圖走一遍“借閱圖書”主流程驗證類圖能不能支撐業(yè)務(wù)。流程大致是管理員掃描圖書條碼系統(tǒng)根據(jù)條碼找到BookCopy檢查該副本狀態(tài)是否“可借”如果可借再校驗ReaderAccount是否有超期未還圖書或未繳罰款校驗通過后創(chuàng)建LoanRecord更新BookCopy狀態(tài)為“借出”最后返回借閱成功。這個時序圖畫下來很容易暴露一個類職責(zé)問題檢查讀者是否有欠款這個邏輯應(yīng)該寫在LoanRecord里還是抽出一個AccountService如果寫在LoanRecord里它的職責(zé)就太重了抽一個AccountService職責(zé)更清晰。所以我說時序圖不只是“畫個流程”它是一個驗證設(shè)計合理性的工具。時序圖能順利走通類圖的職責(zé)分配基本不會有方向性問題走不通說明哪里責(zé)任沒理清該加的類加該拆的類拆。6. 建模實操中的常見問題和避坑建議6.1 新手最容易踩的五個坑第一個坑畫圖前不明確受眾。面向產(chǎn)品經(jīng)理的用例圖和面向開發(fā)的類圖詳細程度完全不同。先問“這圖給誰看”再決定畫到什么粒度。第二個坑濫用依賴關(guān)系和關(guān)聯(lián)關(guān)系。方法參數(shù)里用到類A就畫一條依賴箭頭字段里有個List就畫一條關(guān)聯(lián)箭頭結(jié)果圖亂成一團。我自己的原則是類圖優(yōu)先表達關(guān)聯(lián)、聚合、組合和繼承這四種關(guān)系依賴只在標注某個特定調(diào)用關(guān)系時才畫。第三個坑把所有方法都畫進類圖。類圖是給人看的不是給編譯器看的。方法太多時只畫核心方法的簽名即可其余用省略號一帶而過。第四個坑狀態(tài)圖和活動圖混用。狀態(tài)圖是單個對象在生命周期內(nèi)的“縱向觀察”活動圖是業(yè)務(wù)流程在不同參與者間流動的“橫向觀察”。分不清的時候問問自己圖里有沒有“對象狀態(tài)”有就是狀態(tài)圖沒有純流程節(jié)點就是活動圖。第五個坑畫完圖就當(dāng)甩手掌柜半年不更新。圖是活的文檔不是一次性的交差物品這個毛病得從做項目的第一天就改掉。6.2 建模工具怎么選課件里沒有強推某款工具因為不同場景適合不同工具。學(xué)生黨推薦StarUML跨平臺、支持教學(xué)用途免費許可畫類圖和用例圖操作順暢足夠應(yīng)付課程設(shè)計和畢業(yè)設(shè)計。喜歡寫文本的開發(fā)者可以試試PlantUML用代碼描述圖配合Markdown寫文檔非常舒服而且圖源文件是文本方便版本控制Git diff時能看清改動點。團隊協(xié)作可以用draw.io免費、有網(wǎng)頁版、支持多人實時編輯缺點是比較復(fù)雜的圖排版容易飄。Enterprise Architect這類工具功能極其強大但學(xué)習(xí)成本也極高教學(xué)場景性價比不高不建議初學(xué)者一上來就啃。6.3 講圖比畫圖更考驗功力最后這個經(jīng)驗送給要答辯、要做設(shè)計評審的同學(xué)。畫圖的人容易陷入“我畫的就是對的”思維定勢講圖的時候語速飛快全是自嗨。真實的評審場景里聽眾看一張圖第一眼只關(guān)心三件事核心實體是哪些、實體間的主要關(guān)系是什么、關(guān)鍵的流程從哪到哪。所以講圖要先整體后細節(jié)先用一句話概括這張圖表達的模型是什么再按閱讀順序從上到下或從左到右把關(guān)鍵關(guān)系講清楚最后才提一兩個設(shè)計要點和備選方案。千萬別一上來就鉆進某個類的某個方法那樣聽眾會立刻失去耐心。以上這些都是我一次次踩坑踩出來的體會。第一次講UML的時候我對著圖瘋狂念標簽把“關(guān)聯(lián)”“聚合”這些術(shù)語背得滾瓜爛熟學(xué)員卻全程一臉茫然。后來把“先整體、再關(guān)鍵、后細節(jié)”這套講述方式固定下來課堂反饋才明顯好轉(zhuǎn)。UML本質(zhì)上不復(fù)雜它就是蓋房子之前的建筑施工圖唯一目的是讓所有參與者對齊認知。把它當(dāng)溝通工具用它價值巨大把它當(dāng)成應(yīng)付檢查的文檔那它就是個形式主義。希望這套課件和例子能幫你在真實項目里把圖畫起來、用起來而不是讓UML永遠停留在書架和課件里吃灰。本文還有配套的精品資源點擊獲取