Posted inAI AI Chatbot UML

創建簡單線上食物訂購系統UML部署圖的完整指南

1. UML部署圖的目的

一個部署圖顯示系統的實體/執行時期架構：

  • 硬體節點（伺服器、裝置、雲端實例）
  • 部署在這些節點上的軟體實體
  • 執行環境（容器、執行時）
  • 節點之間的通訊路徑（通訊協定、連接）

針對一個簡單線上食物訂購系統，它可視化如何：

  • 客戶與餐廳的網頁介面是如何提供服務的
  • 業務邏輯如何運作
  • 資料如何儲存
  • 外部服務（付款、通知）如何整合

它幫助開發人員、DevOps 和利益相關者理解部署拓撲、擴展點、安全邊界與相依性。

2. 部署圖中的關鍵UML元素

元素 UML符號（PlantUML） 意義／何時使用 範疇範例
節點 node 「名稱」 可主機實體的運算資源（實體或虛擬） <<裝置>>、<<雲端>>
設備 節點「名稱」<<設備>> 實體或虛擬硬體（伺服器、行動裝置、路由器） <<設備>>, <<伺服器>>
執行環境 節點「名稱」<<執行環境>> 軟體執行時/容器（Tomcat、Node.js、Docker、JVM） <<執行環境>>, <<容器>>
工件 工件「filename.war」 可部署單元（可執行檔、.jar、.js 套件、資料庫結構、設定檔） <<可執行檔>>, <<檔案>>, <<資料庫>>
組件 組件「名稱」 邏輯軟體單元（在部署圖中為可選；通常由工件實現） <<網頁>>, <<服務>>
通訊路徑 –, –>, ..> 節點之間的網路連接（可具有通訊協定標籤） HTTP/HTTPS、WebSocket、RMI
依賴 / 呼叫 ..>, –> 使用/依賴（例如：前端呼叫後端） <<呼叫>>, <<存取>>
顯現 / 實現 ..> 搭配 <<實現>> 或 ..> 工件實現 / 部署為組件 <<實現>>, <<顯現>>
外部系統 節點「名稱」<<外部>> 您無法控制的第三方服務 <<外部>>, <<SaaS>>

3. 部署圖的最佳實務（特別適用於網路系統）

  • 保持簡單且易讀簡單且易讀 — 避免過度擁擠；每個主要環境（開發/測試/生產，可選）使用一個圖表
  • 使用有意義的節點分組（將節點嵌套在節點內）以顯示叢集／雲端區域
  • 優先使用簡潔的符號 — 僅在相關時顯示檔案名稱／設定；跳過冗餘的樣式
  • 清楚顯示邊界 — 內部雲端與外部服務
  • 標示通訊協定於路徑上（HTTP/HTTPS、WebSocket、TCP 等）
  • 使用由左至右的方向 於網路系統中（客戶端 → 伺服器 → 資料庫的流程感覺自然）
  • 區分裝置（硬體）與執行環境（執行時期）
  • 僅在有價值時顯示實作僅在具有價值時（元件實作於元件）
  • 使用skinparam在 PlantUML 中以獲得更好的顏色/可讀性
  • 適用於小型/中型系統：最多 4–8 個節點

4. 簡單線上點餐系統的推薦架構

此系統的乾淨、現代化佈局：

  • 客戶端 → 瀏覽器（隱含）與 …… 通訊Web 伺服器/CDN
  • Web 伺服器/CDN 主機靜態資源與 SPA 檔案，用於客戶網站與餐廳管理介面
  • API 伺服器（執行環境）執行後端邏輯
  • 資料庫伺服器 主機 PostgreSQL
  • 外部 支付與通知服務

常見節點：

  1. Web 伺服器 / CDN <<裝置>>
  2. API 伺服器 <<執行環境>>
  3. 資料庫伺服器 <<執行環境>>
  4. 支付網關 <<外部>>
  5. 通知服務 <<外部>>

5. 由 Visual Paradigm AI 聊天機器人生成的圖示

改良並清理過的 PlantUML 程式碼（含說明）

@startuml

標題：簡單線上點餐系統 – 部署圖

從左到右方向

skinparam {
ArrowColor #424242
ArrowFontColor #424242
預設字體大小 14
陰影 false
stereotypeC背景顏色 #ADD1B2
stereotypeI背景顏色 #ADD1B2
}

‘ ── 節點 ────────────────────────────────────────────────

節點 “Web 伺服器 / CDN” <<裝置>> 稱為 WebServer {
[客戶網站 HTML/JS/CSS] #..# (客戶 SPA)
[餐廳管理介面 HTML/JS/CSS] #..# (餐廳 SPA)
}

節點 “雲端後端” <<裝置>> 稱為 Cloud {
節點 “API 伺服器” <<執行環境>> 稱為 APIServer {
元件 “backend-api.jar / main.exe” 稱為 BackendArtifact
}

節點 “PostgreSQL 伺服器” <<執行環境>> 稱為 DBServer {
資料庫 “PostgreSQL 資料庫” 稱為 Postgres <<資料庫>>
}
}

節點 “付款網關” <<外部>> 稱為 Payment {
[付款 API] 稱為 PaymentAPI
}

節點 “通知服務” <<外部>> 稱為 Notification {
[WebSocket / 推播 API] 稱為 NotifyAPI
}

‘ ── 關係 ─────────────────────────────────────────

WebServer –> Cloud : HTTPS (API 呼叫)

Cloud –> Payment : HTTPS (結帳)

Cloud –> Notification : WebSocket / HTTPS (狀態更新)

‘ 元件 → 組件實作 (可選但清晰)
(客戶 SPA) ..> BackendArtifact : <<呼叫>>
(餐廳SPA) ..> 後端實體 : <<呼叫>>

後端實體 –> Postgres : <<JDBC / SQL>>

後端實體 –> 支付API : <<HTTPS呼叫>>

後端實體 –> 通知API : <<WebSocket / HTTPS>>

‘ 可選：若需要，可在資料庫上顯示通訊協定
‘ 後端實體 -右-> Postgres : <<JDBC>>

note right of Cloud
典型的中小型設定：
• 單一虛擬機器或小型叢集
• API + 資料庫可位於同一部機器上（為簡化起見）
或分離以獲得更好的擴展性
end note

@enduml

6. 分步指南：如何建立自己的部署圖

  1. 列出所有執行目標（伺服器、容器、外部服務）
  2. 列出可部署的實體（實際執行的內容：.js 套件、.jar、資料庫）
  3. 分組為節點（在邏輯上嵌套——例如：API + 資料庫位於同一雲端節點）
  4. 決定方向（從左到右對 web → API → DB 來說效果良好）
  5. 新增通訊路徑並加上通訊協定標籤
  6. 新增關鍵依賴關係（<<呼叫>>，<<存取>>）
  7. 套用 skinparam以提升色彩表現與可讀性
  8. 新增註解用於重要決策（單一 vs 多個執行個體、擴展性註解）
  9. 驗證: DevOps工程師能否理解每個組件應部署在哪裡？

摘要 – 簡單食物訂購部署快速參考

部分 典型節點類型 物件範例 透過以下方式連接
客戶使用者介面 Web 伺服器 / CDN <<裝置>> SPA 套件 (HTML/JS) HTTPS → API
餐廳儀表板 Web 伺服器 / CDN <<裝置>> 管理員 SPA 套件 HTTPS → API
商業邏輯 API 伺服器 <<執行環境>> backend-api.jar / 可執行檔 JDBC → 資料庫，HTTPS → 外部
資料儲存 PostgreSQL <<執行環境>> PostgreSQL 資料檔 + 資料結構 —
付款 外部 <<SaaS>> 付款 API 端點 HTTPS
即時更新 外部 <<SaaS>> WebSocket / FCM / APNs WebSocket / HTTPS

此結構對於MVP或中小型規模部署（1–3台伺服器 + 雲端資料庫 + Stripe/PayPal + Firebase/Pusher）而言是現實可行的。

當系統擴展時，可自由調整巢狀結構、通訊協定，或新增擴展說明（例如負載平衡器、複本等）。

🔗 參考清單（Markdown 格式）