簡介這份UML課程設(shè)計停車場管理系統(tǒng)軟件系統(tǒng)分析與設(shè)計文檔以停車場管理系統(tǒng)為載體完整呈現(xiàn)從需求分析到軟件建模的課程設(shè)計全過程適合軟件工程專業(yè)學(xué)生、UML建模學(xué)習(xí)者以及課程設(shè)計備賽者參考借鑒。文檔系統(tǒng)梳理了系統(tǒng)的功能性需求與非功能性需求并配有需求分析規(guī)格說明書、系統(tǒng)用例圖以及靜態(tài)模型中的分析包、分析類圖和分析對象圖同時覆蓋順序圖、協(xié)作圖、狀態(tài)圖、活動圖等動態(tài)模型和數(shù)據(jù)庫設(shè)計章節(jié)可作為課程設(shè)計說明書模板使用。文檔以doc格式封裝共1個文件壓縮包僅249KB輕量易用。目前已有3474人學(xué)習(xí)使用。通過該文檔讀者可以系統(tǒng)掌握UML建模在實際業(yè)務(wù)場景中的落地方法理解車位管理、停車記錄管理、費用計算、報表生成等核心模塊的類圖與對象圖設(shè)計并借鑒從需求到設(shè)計各階段的文檔組織思路與細節(jié)處理方法從而更高效地完成同類課程設(shè)計任務(wù)。1. UML課程設(shè)計停車場管理系統(tǒng)分析與設(shè)計一份課程設(shè)計為什么值得按工程標(biāo)準(zhǔn)做如果你的課程設(shè)計題目是「UML課程設(shè)計停車場管理系統(tǒng)軟件系統(tǒng)分析與設(shè)計」先想清楚一個事實這不是讓你去寫一個能跑的商業(yè)停車場系統(tǒng)而是考察你能不能把一套模糊的業(yè)務(wù)需求通過 UML 語言逐步翻譯成清晰、可驗證、能指導(dǎo)后續(xù)開發(fā)的軟件系統(tǒng)分析與設(shè)計文檔。很多同學(xué)在這個題目上翻車不是代碼能力不行而是把大量時間花在畫漂亮的用例圖上最后交上去的模型經(jīng)不起一句追問這個用例的邊界是什么這條消息的順序為什么這樣排類之間的關(guān)聯(lián)基數(shù)你是怎么確定的這篇筆記我會按一個完整課程設(shè)計的推進順序來拆先識別角色和用例邊界再做靜態(tài)結(jié)構(gòu)建模再做動態(tài)行為建模最后落到包圖、部署圖和數(shù)據(jù)庫設(shè)計最后給你一份答辯前自查的避坑清單。全程以停車場管理系統(tǒng)為主線所有步驟、圖表規(guī)格和文檔組織方式你都可以直接照著復(fù)現(xiàn)。整篇文章讀完你應(yīng)該能回答三個問題這套 UML 模型要畫哪些圖、每張圖畫到什么粒度算合格、模型之間的一致性如何檢查。下面進入正題。我們先把最容易出錯、也最容易被老師追問的「用例驅(qū)動」這一步講透。2. 用例驅(qū)動先定角色和邊界再談畫圖UML 建模不是從類圖開始的是從用例開始的。停車場管理系統(tǒng)雖然業(yè)務(wù)看起來不復(fù)雜——車輛進場、出場、繳費、找車位——但一旦涉及多個角色、多個計費規(guī)則、多種支付方式用例邊界稍微模糊一點后面的類圖和順序圖全部跟著亂。2.1 角色識別誰在用停車場誰在用系統(tǒng)做用例分析的第一步不是畫圖是找參與者。停車場管理系統(tǒng)最常見的誤區(qū)是把「車」當(dāng)成參與者正確的做法是問一句誰主動觸發(fā)了系統(tǒng)的功能我一般用一個簡單的排除法把需求描述里的名詞全部列出來然后問三個問題——它有沒有自己的目標(biāo)它是否主動發(fā)起操作它是否需要與系統(tǒng)交互滿足其中任意一條才考慮作為參與者。按這個標(biāo)準(zhǔn)停車場管理系統(tǒng)的參與者通常有兩類外部參與者和外部系統(tǒng)。外部參與者包括車主駕車人、停車場管理員、系統(tǒng)管理員。車主觸發(fā)入場、出場、繳費、預(yù)約等用例停車場管理員處理異常放行、設(shè)備故障、人工收費系統(tǒng)管理員維護費率、用戶權(quán)限、日志。外部系統(tǒng)則包括車牌識別設(shè)備、支付網(wǎng)關(guān)、短信/消息推送服務(wù)。注意車牌識別設(shè)備和支付網(wǎng)關(guān)是「外部系統(tǒng)」不是「參與者」畫用例圖時寫在系統(tǒng)邊界外用「系統(tǒng)」圖標(biāo)而不是「人形」圖標(biāo)表示這也是老師在評分時容易盯住的細節(jié)。另外還有一種情況預(yù)約場景里可能存在「車主」和「場內(nèi)車輛」的對應(yīng)關(guān)系同一個人類角色在訪客預(yù)約和按月租用車位兩個場景中權(quán)限不同這時要拆成兩個用例而不是一個用例下掛多個分支。識別完角色后下一步才是把每個角色能做的動作整理成用例清單。工具上我建議在正式開始畫之前先用一個簡單的表格把參與者、目標(biāo)、關(guān)鍵用例列出來相當(dāng)于給自己做一份領(lǐng)域詞匯表。這樣到畫圖的時候參與者的命名、用例的命名基本都不會飄。2.2 用例圖畫法主用例、包含關(guān)系和擴展關(guān)系的落地標(biāo)準(zhǔn)用例圖本身很簡單難的是用例命名和關(guān)系選擇。我見過太多人把「車輛入場管理」「車輛出場管理」「車位管理」「收費管理」這種「管理」后綴當(dāng)成用例名。這里記住一個標(biāo)準(zhǔn)用例名必須是動詞短語表達一個可觀察的、為用戶產(chǎn)生價值的動作。比如「入場車輛識別」「計算停車費用」「執(zhí)行出場繳費」「預(yù)約車位」。帶上「管理」兩個字說明你還沒想清楚這個用例到底是做什么的。主用例怎么找對停車場系統(tǒng)來說核心價值鏈路是「入場 — 找車位 — 出場繳費」這三件事就是主用例。剩下的都是輔助用例異常放行、費用申訴、費率調(diào)整、報表統(tǒng)計。主用例之間的關(guān)系要特別注意「包含」和「擴展」的區(qū)別。我見過大量同學(xué)把「微信支付」「支付寶支付」畫成支付用例的擴展這是典型的理解偏差。包含關(guān)系include表示一個用例總是會調(diào)用另一個用例是必選的比如「出場繳費」總是包含「計算停車費用」箭頭從基礎(chǔ)用例指向被包含用例。擴展關(guān)系extend表示某個條件滿足時才觸發(fā)的附加行為是可選分支比如「出場繳費」在支付超時后擴展「延長繳費時限」箭頭從擴展用例指向基礎(chǔ)用例方向正好相反。在實際交付中用例圖還要做一次「橫向評審」每個參與者至少對應(yīng)一個用例每個用例至少要有一個參與者觸發(fā)出現(xiàn)沒有參與者的用例說明它在當(dāng)前場景里不成立出現(xiàn)沒有用例的參與者說明該參與者要么多余要么漏了功能。這一步做下來幾乎每一份課程設(shè)計都能發(fā)現(xiàn)至少兩個漏掉的場景最常見的就是管理員改費率之后正在場內(nèi)停車的車輛費率怎么算這個沒有用例覆蓋。2.3 用例規(guī)格說明一個用例一張表讓圖替不了的責(zé)任落在文字上用例圖只是索引真正決定評分高低的是用例的文字描述。這部分我建議做成一張規(guī)整的規(guī)格說明表每個核心用例一張放在附錄而不堆在正文里干擾主線閱讀。規(guī)格表至少要有六列用例編號、參與者、前置條件、基本事件流、備選事件流、后置條件。拿「出場繳費」舉例。前置條件是車輛已停放在庫內(nèi)且車牌已被識別?；臼录饔镁幪柌襟E寫1. 系統(tǒng)通過車牌識別設(shè)備讀取車牌2. 系統(tǒng)查詢車輛入場記錄和當(dāng)前費率3. 系統(tǒng)計算停車時長與費用4. 系統(tǒng)生成待支付訂單5. 車主完成支付6. 系統(tǒng)確認到賬7. 系統(tǒng)抬桿放行。備選事件流要寫清楚什么情況下會走哪條分支車牌識別失敗走人工輸入費用爭議走管理員介入支付超時走延長繳費或鎖定訂單。后置條件是訂單狀態(tài)變更為已支付車輛放行記錄已生成。這里有一個非常容易被老師抓住的漏洞基本事件流寫了步驟 3「計算停車時長與費用」卻沒有在備選事件流里寫「入場記錄缺失」的情況——比如抬桿故障導(dǎo)致車輛沒有入場記錄就進庫了。遇到這種情況系統(tǒng)怎么處理不寫說明你的流程思考不閉環(huán)。寫就需要在類圖里增加「人工補錄入場記錄」的類這一步也反哺了下一步的靜態(tài)建模。在文字組織上基本事件流建議控制 5 到 8 步多了說明用例粒度太大拆開少了說明寫得太粗補細節(jié)。備選事件流至少寫 3 條這是課程設(shè)計與工程交付最直觀的差距前者寫一條「異常退出」就算完事后者會把每一種真實業(yè)務(wù)分支都列出來。3. 靜態(tài)建模類圖與對象圖把結(jié)構(gòu)釘死用例確定行為邊界類圖確定結(jié)構(gòu)。停車場管理系統(tǒng)的類圖通常要求覆蓋核心業(yè)務(wù)對象加上它們之間的關(guān)系如果課程設(shè)計要求附帶數(shù)據(jù)庫設(shè)計類圖直接決定后續(xù)表結(jié)構(gòu)所以這一步值得花心思做細。3.1 從需求描述里找候選類三個實用的識別方法第一個方法叫名詞篩選法閱讀需求描述把名詞圈出來。車輛、車位、車主、收費記錄、入場記錄、出場記錄、費率、訂單、支付、優(yōu)惠券、管理員、設(shè)備、停車場、樓層、通道這聽起來很簡單但要注意過濾掉「偶然名詞」和「屬性名詞」。舉個例子「車牌號」不應(yīng)該作為類它是車輛類的屬性「繳費窗口」不應(yīng)該作為類它只是支付訂單的一個展示角度不是獨立概念。第二個方法叫邊界確認法區(qū)分「值的對象」和「實體對象」。實體對象有唯一標(biāo)識比如車輛、車位、訂單、費率它們跨會話存在要建類值的對象只是描述性數(shù)據(jù)比如金額、時間戳、時長不應(yīng)該作為獨立類。按這個標(biāo)準(zhǔn)停車費率是一個實體因為一份費率可能在多個訂單中復(fù)用支付金額不是實體它是訂單的屬性。這條規(guī)則能攔住大部分初學(xué)者常見的「什么都要建類」的沖動。第三個方法叫場景反推法先給出系統(tǒng)邊界內(nèi)的核心業(yè)務(wù)事件再反推處理這些事件需要哪些數(shù)據(jù)。入場事件需要車牌和入場時間對應(yīng)入場記錄類費用計算事件需要入場時間、出場時間和費率對應(yīng)費率類和訂單類預(yù)約事件需要車主信息和目標(biāo)車位對應(yīng)預(yù)約類。我用這個方法幫一個同學(xué)排查過他類圖里漏了「停車場」類的層級關(guān)系——車場有多個樓層樓層有多個車位這三個層級的歸屬關(guān)系不建出來后面部署圖和數(shù)據(jù)庫設(shè)計一定亂。3.2 類圖繪制與關(guān)系基數(shù)不要憑感覺寫 1 對多類圖畫出來后最重要的環(huán)節(jié)是關(guān)系關(guān)系的確定。常見的關(guān)系有四種關(guān)聯(lián)、聚合、組合、泛化。關(guān)聯(lián)表示兩個類之間有語義連接比如「車主」和「車輛」是關(guān)聯(lián)關(guān)系。聚合表示整體與部分但部分可以脫離整體存在比如「停車場」和「車位」是聚合關(guān)系——車位即使從停車場中移除它還是一個車位只是不在這個場里。組合表示整體與部分并且部分不能脫離整體存在比如「訂單」和「訂單明細」是組合關(guān)系——訂單明細離開訂單沒有意義。泛化就是繼承「普通費率」和「時段費率」都繼承「費率」?；鶖?shù)要按業(yè)務(wù)規(guī)則推不要拍腦袋。一個車主可以有多輛車一輛車被一個車主使用所以「車主 1 — 車輛 *」。一個訂單只屬于一輛車一輛車可能產(chǎn)生多個訂單所以「車輛 1 — 訂單 *」。一個車位在同一時刻只能被一個訂單占用一個訂單可以占用多個車位——比如大車占兩個車位——這里是「車位 1 — 訂單 *」但如果你的系統(tǒng)明確只支持一車一位就寫「車位 1 — 訂單 1」?；鶖?shù)寫錯比關(guān)系類型寫錯更常見因為關(guān)系類型可以從語義判斷基數(shù)卻需要結(jié)合業(yè)務(wù)規(guī)則逐條核對。屬性與方法也不要隨意堆。每個類先寫標(biāo)識屬性如車輛類的車牌號、車位類的車位編號再寫業(yè)務(wù)屬性如訂單類的入場時間、出場時間、費用金額方法只寫對外職責(zé)如訂單類提供 calculateFee 方法內(nèi)部的 getter/setter 通常不畫進類圖否則類圖會膨脹成一堆沒意義的箱子。在方法命名上盡量用動詞短語而非名詞和用例的命名習(xí)慣保持統(tǒng)一。3.3 對象圖反向校驗用具體實例驗證類設(shè)計對象圖容易被忽視但它是驗證類設(shè)計正確性的有力工具。畫對象圖就是給類圖填具體數(shù)據(jù)看這個類結(jié)構(gòu)在真實場景下能不能跑通。比如你定義了「訂單」和「車位」兩個類關(guān)系是「訂單 * — 車位 1」。現(xiàn)在做一個「一輛車連續(xù)停兩天」的對象圖實例車輛 A 在第一天生成訂單 1占用車位 B第二天續(xù)停生成訂單 2仍占用車位 B。對象圖里就出現(xiàn)兩個訂單對象同時連接到同一個車位對象。這時你就要考慮這兩個訂單是重疊時間段還是連續(xù)時間段如果系統(tǒng)不允許同一個車位被兩個訂單時間重疊占用類里就要加一個時間約束或者把「車位占用」提升為一個獨立的類記錄占用開始時間和結(jié)束時間。這就是對象圖的價值。我在實際做的時候會把核心業(yè)務(wù)場景做成三張對象圖正常入場出場、預(yù)約占位、月租車輛續(xù)費。每張對象圖數(shù)據(jù)不同跑一遍下來類之間的關(guān)系和約束基本能查缺補漏。4. 動態(tài)建模順序圖、狀態(tài)圖和活動圖的分工與畫法動態(tài)建模是 UML 課程設(shè)計中最容易互相覆蓋的部分。順序圖、狀態(tài)圖、活動圖畫哪幾張、畫到什么粒度需要有清晰的判斷標(biāo)準(zhǔn)。籠統(tǒng)地說順序圖強調(diào)「某一次具體交互中的消息時序」?fàn)顟B(tài)圖強調(diào)「一個對象的生命周期」活動圖強調(diào)「跨多個對象的業(yè)務(wù)流程流向」。4.1 順序圖消息順序才是靈魂順序圖最常見的錯誤是一張圖塞進太多場景。正確做法是一個用例對應(yīng)一張順序圖圖里的對象盡量控制在 4 到 6 個消息控制在 8 到 15 條。以「出場繳費」為例參與者是車主對象依次是車牌識別設(shè)備、入場記錄、費率、訂單、支付網(wǎng)關(guān)。消息順序大致是車牌識別設(shè)備返回車牌號給訂單訂單向入場記錄查詢?nèi)雸鰰r間訂單向費率獲取當(dāng)前計費規(guī)則訂單計算費用訂單向支付網(wǎng)關(guān)發(fā)起扣款支付網(wǎng)關(guān)返回支付結(jié)果訂單更新狀態(tài)然后系統(tǒng)控制抬桿。順序圖里選對象有個小技巧優(yōu)先選已經(jīng)出現(xiàn)在類圖里的類這樣動態(tài)圖才能和靜態(tài)圖對得上否則評審時會被問到——這個順序圖里的某某對象為什么不在類圖里答案無外乎兩種要么類圖漏了要么順序圖畫錯了。順序圖里不應(yīng)出現(xiàn)類圖中不存在的對象這類一致性問題在評分中非常致命。關(guān)于消息編號課程設(shè)計文檔里建議在每個消息前加序號比如 1: getEntryTime()、2: calcFee()。這么做的好處是答辯時可以直接按序號把整個流程講下來不用在圖上找線。同步消息用實心箭頭返回消息用虛線箭頭。異步消息在停車場系統(tǒng)里有典型場景——支付網(wǎng)關(guān)返回支付結(jié)果這里適合畫異步接收車輛先抬桿出場支付結(jié)果后臺到達。要不要把這個異步細節(jié)畫出來主要看你的課程設(shè)計是否涉及消息隊列不涉及的話可以不畫避免給自己增加復(fù)雜度。4.2 狀態(tài)圖車位和訂單是兩個必須畫的狀態(tài)機停車場系統(tǒng)里最值得畫狀態(tài)圖的對象有兩個車位和訂單。車位狀態(tài)機大致是空閑 → 預(yù)定預(yù)約成功后→ 占用車輛入場→ 空閑車輛出場。這里要注意「預(yù)定」?fàn)顟B(tài)到「占用」?fàn)顟B(tài)的轉(zhuǎn)換條件按預(yù)約時段入場才轉(zhuǎn)占用超時未入場則轉(zhuǎn)空閑。另一種情況是預(yù)約后用戶取消也要從預(yù)定轉(zhuǎn)回空閑。如果不畫這條分支說明預(yù)約場景沒有考慮取消邏輯。訂單狀態(tài)機更復(fù)雜也更重要已創(chuàng)建 → 待支付 →支付成功已支付 → 已完成或者 已創(chuàng)建 → 待支付 →支付超時已關(guān)閉。這里有個容易被忽略的細節(jié)——在停車場景里訂單可能正在停靠中就已生成車輛當(dāng)前占用車位但費用尚未計算。如果你把訂單狀態(tài)畫成「創(chuàng)建—支付—完成」和實際業(yè)務(wù)不符。更準(zhǔn)確的寫法是引入「?？恐小?fàn)顟B(tài)車輛入場生成停靠中訂單出場時結(jié)算并轉(zhuǎn)待支付支付成功后轉(zhuǎn)已支付。這個細節(jié)是答辯時的加分項因為它體現(xiàn)了你真正理解業(yè)務(wù)狀態(tài)流轉(zhuǎn)而不是套模板。畫狀態(tài)圖還要標(biāo)好事件的觸發(fā)條件。狀態(tài)圖的名字是「狀態(tài)」但真正有價值的是「轉(zhuǎn)換」——從占用轉(zhuǎn)空閑的事件是車輛出場從待支付轉(zhuǎn)已支付的事件是支付成功回調(diào)。事件名要寫清楚不要寫「改變」要寫「outVehicle() 返回」「paymentResult 為 SUCCESS」。4.3 活動圖跨角色流程用活動圖別當(dāng)順序圖用活動圖適合表達跨角色、有判斷分支的流程。停車場系統(tǒng)里最有代表性的是「異常車輛出場處理」車輛到出口車牌識別失敗活動圖進入判斷——是否人工輸入車牌人工輸入后系統(tǒng)再次查詢?nèi)雸鲇涗浫缓笈袛噘M用是否有爭議有爭議轉(zhuǎn)人工審核無爭議進入正常繳費流程。這個流程跨越車主、管理員、系統(tǒng)三個對象有清晰的分支判斷畫成活動圖比順序圖更直觀。畫活動圖時泳道按參與者劃分每個動作放在對應(yīng)泳道里。判斷節(jié)點用菱形表示分支條件寫在連線上。初學(xué)者常犯的錯誤是每個步驟都加判斷導(dǎo)致活動圖里菱形比矩形還多。判斷節(jié)點只在業(yè)務(wù)規(guī)則真正分叉的地方加比如「是否超時」「是否有入場記錄」而不是「是否輸入車牌成功」這種過程性操作也畫進去。另外活動圖和順序圖切忌雙軌制同一場景既畫了順序圖又畫了活動圖或者兩個圖里的消息順序不一致。我的做法是核心用例畫順序圖跨角色的異常流程畫活動圖圖面有重疊時先畫活動圖確認分支再從某個分支抽出來畫順序圖這樣動態(tài)模型整體保持一致不至于各畫各的。5. 從分析到設(shè)計包圖、部署圖、數(shù)據(jù)庫設(shè)計和工具選型UML 課程設(shè)計如果只畫完用例圖和類圖就交卷等于只完成了分析沒有完成設(shè)計。課程題目里寫著「軟件系統(tǒng)分析與設(shè)計」后半部分要落地為包圖、部署圖和數(shù)據(jù)庫結(jié)構(gòu)這部分決定了報告的技術(shù)深度。5.1 包圖劃分原則按層次分包不要按業(yè)務(wù)模塊分包包圖的作用是表達系統(tǒng)的模塊化組織。常見做法是把系統(tǒng)分成三層表示層、業(yè)務(wù)邏輯層、數(shù)據(jù)訪問層對應(yīng)常見的分層架構(gòu)。在表示層放界面相關(guān)的類在業(yè)務(wù)邏輯層放訂單、費率、車輛等核心業(yè)務(wù)類在數(shù)據(jù)訪問層放數(shù)據(jù)庫操作、外部接口適配的類。按層次分包而不是按業(yè)務(wù)模塊分包是因為停車場系統(tǒng)的業(yè)務(wù)邊界相對清晰模塊分包容易導(dǎo)致循環(huán)依賴。舉個例子如果你把「收費模塊」和「車輛管理模塊」分成兩個包收費模塊需要訪問車輛信息車輛管理模塊又需要調(diào)收費模塊計算費用兩個包之間就產(chǎn)生了循環(huán)依賴。按層次劃分后表示層 → 業(yè)務(wù)邏輯層 → 數(shù)據(jù)訪問層是單向依賴每一層只能依賴下一層不會出現(xiàn)循環(huán)。這個判斷在答辯時非常加分因為它是架構(gòu)層面的思維不是畫圖層面的工作。包圖里每個包要寫明內(nèi)部包含的類名至少列出核心類。包之間的關(guān)系用虛線箭頭表示依賴不要用實線關(guān)聯(lián)因為包和包之間是「存在依賴」而不是「強關(guān)聯(lián)」。5.2 部署圖與數(shù)據(jù)庫設(shè)計UML 怎么落到物理實現(xiàn)部署圖描述系統(tǒng)的物理節(jié)點和節(jié)點上的構(gòu)件。停車場管理系統(tǒng)常見的節(jié)點有前端管理終端、應(yīng)用服務(wù)器、數(shù)據(jù)庫服務(wù)器、車牌識別設(shè)備。應(yīng)用服務(wù)器上部署業(yè)務(wù)邏輯構(gòu)件數(shù)據(jù)庫服務(wù)器上部署數(shù)據(jù)存儲。如果課程設(shè)計只做單機版部署圖可以簡單畫一個節(jié)點但如果題目強調(diào)「系統(tǒng)分析與設(shè)計」建議至少畫出前端、后端、數(shù)據(jù)庫三個節(jié)點的部署關(guān)系這樣才體現(xiàn)軟件系統(tǒng)的物理部署結(jié)構(gòu)。數(shù)據(jù)庫設(shè)計這一步即使課程設(shè)計沒有單獨要求畫數(shù)據(jù)庫圖也強烈建議提供一套實體關(guān)系表和建表語句。原因很簡單數(shù)據(jù)庫表結(jié)構(gòu)就是類圖的物理映射。訂單表對應(yīng)訂單類車輛表對應(yīng)車輛類車位表對應(yīng)車位類。類圖里寫明了關(guān)系數(shù)據(jù)庫里就要有對應(yīng)的外鍵設(shè)計。我在實際參與課程設(shè)計指導(dǎo)時發(fā)現(xiàn)很多同學(xué)類圖畫得很好但數(shù)據(jù)庫表只有一張訂單表一張車位表完全體現(xiàn)不了類圖中的關(guān)系等于分析階段和設(shè)計階段斷開了。一個針對停車場系統(tǒng)的參考設(shè)計是這樣車輛表車牌號、車主ID、車型車位表車位ID、樓層、類型、狀態(tài)停車訂單表訂單ID、車牌號、車位ID、入場時間、出場時間、費用狀態(tài)費率表費率ID、生效時間、單價、適用時段。停車訂單表和車輛表之間通過車牌號關(guān)聯(lián)和車位表之間通過車位ID關(guān)聯(lián)和費率表之間通過費率ID關(guān)聯(lián)。建表時注意時間字段統(tǒng)一用一種類型金額字段用十進制而不是浮點數(shù)避免金額計算精度問題。這是實踐中最常見的細節(jié)坑。5.3 工具選型畫圖工具怎么選一致性與可追溯性怎么保證UML 工具的選擇直接影響產(chǎn)出效率。常見的有三類一類是專用建模工具適合完整建模流程但需要安裝配置另一類是輕量繪圖工具上手快但模型之間沒有強約束無法做一致性檢查還有一類是代碼化建模工具用文本描述圖適合放進版本管理。對課程設(shè)計場景我建議至少用一個能滿足三點的工具能繪制類圖并管理關(guān)系、能導(dǎo)出圖片、能方便修改。具體選哪個看你本機環(huán)境而定不必人云亦云。更重要的是模型一致性的維護方法。很多同學(xué)是畫完用例圖畫類圖畫完類圖畫順序圖中間從不回頭檢查。結(jié)果交上去的文檔順序圖里的對象在類圖里找不到類圖里的類在用例規(guī)格里沒有對應(yīng)。我給自己定的一條紀律是每畫完一張圖回頭檢查上一張圖把不一致的地方當(dāng)場改掉。比如畫完順序圖再回看類圖確認消息里調(diào)用的方法在類圖的方法列表里出現(xiàn)了確認參與者和用例的關(guān)系還沒有變化。文檔排版上正文中每張圖下面配一段「圖注 說明」說明寫清楚這張圖要表達什么、關(guān)鍵關(guān)系在哪里。課程設(shè)計報告評分時老師不會一張圖一張圖地去推他會先讀文字再對照圖看你要表達的是不是和文字一致。文字與圖不一致比你圖本身畫錯更傷分數(shù)。6. 答辯與自查5 類高頻硬傷和一份驗證清單6.1 五類答辯時被追問就會露餡的低級錯誤第一是「用例圖漏了外部系統(tǒng)」。車牌識別設(shè)備和支付網(wǎng)關(guān)在圖上是畫在系統(tǒng)邊界外的很多同學(xué)會忽略這一點把設(shè)備畫進系統(tǒng)邊界內(nèi)答辯時被問「設(shè)備是系統(tǒng)的一部分還是外部系統(tǒng)」回答不上來。第二是「順序圖中的消息沒有操作數(shù)」。順序圖里每條消息都應(yīng)該對應(yīng)類圖中的一個方法很多同學(xué)畫了 getData()、setStatus() 這類方法問具體是哪個類的哪個方法答不出。第三是「狀態(tài)圖的轉(zhuǎn)換條件缺失」。車位狀態(tài)圖里從「預(yù)定」轉(zhuǎn)「占用」不寫轉(zhuǎn)換條件等于沒說。答辯時老師只需要問「什么時候從預(yù)定變成占用」你補上一個條件這段就過關(guān)了。第四是「類圖中泛化關(guān)系誤用」。把「車位」和「普通車位」「超大車位」畫成泛化關(guān)系邏輯上沒錯但如果這兩個子類沒有各自的屬性行為泛化就是空殼不如用車位類型字段替代。第五是「全篇圖之間不自洽」。這是最高頻的硬傷——用例事件流寫了「支持月租車輛續(xù)費」類圖里卻沒有月租相關(guān)的類和關(guān)系數(shù)據(jù)庫里也沒有月租訂單表。自洽性檢查其實不復(fù)雜就是逐層對一遍但大多數(shù)人沒有這個習(xí)慣。6.2 一條快速自查路徑我最后提交前會按下面的順序走一遍全程不超過半小時。第一步用例圖和用例規(guī)格說明對照確認每個編號都有對應(yīng)文字。第二步用例規(guī)格里的每個業(yè)務(wù)名詞在類圖里能找到對應(yīng)類或?qū)傩?。第三步類圖里的關(guān)系逐條問為什么是聚合不是組合基數(shù)為什么是 1 對多第四步順序圖的消息逐條對照類圖的方法對象對照類名。第五步數(shù)據(jù)庫表結(jié)構(gòu)對照類圖外鍵關(guān)系與類關(guān)系一致。第六步部署圖的節(jié)點與數(shù)據(jù)庫、應(yīng)用服務(wù)器的數(shù)據(jù)流對應(yīng)。如果你時間緊張至少要保證第三步和第五步——這兩步是最常被挑毛病的地方。6.3 答辯前的小習(xí)慣我習(xí)慣在答辯前一天把全稿打印出來一張圖配一段文字從頭讀一遍遇到「這一步為什么要這樣」「這個判斷從哪里來」的疑問現(xiàn)場記下來第二天主動在答辯里講清楚。這個方法救過我太多次因為圖紙和文字刷在屏幕上時眼睛會慣性跳過問題打印出來以后大腦切換審閱模式很多邏輯斷點才會暴露。答辯的時候被問到不會的問題不要硬撐把自己的思路說清楚承認「這塊我當(dāng)時沒有考慮周全但如果要補充我會這樣做」——這比沉默或亂答要好得多。停車場管理系統(tǒng)的 UML 課程設(shè)計本質(zhì)上不是在考你會畫幾種圖而是在考你有沒有形成一套「從需求到模型再到設(shè)計」的完整思維鏈。希望這篇筆記能幫你在交付之前把這條鏈上的每個環(huán)節(jié)都釘穩(wěn)。本文還有配套的精品資源點擊獲取