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 <<device>>
  2. API 伺服器 <<executionEnvironment>>
  3. 資料庫伺服器 <<executionEnvironment>>
  4. 支付網關 <<external>>
  5. 通知服務 <<external>>

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

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

Plantuml


在 VPasCode 中編輯 Plantuml
Plantuml Edit Plantuml in VPasCode 
@startuml

title 簡單線上點餐系統 - 部署圖

從左到右方向

skinparam {
ArrowColor #424242
ArrowFontColor #424242
DefaultFontSize 14
shadowing false
stereotypeCBackgroundColor #ADD1B2
stereotypeIBackgroundColor #ADD1B2
}

' ── 節點 ────────────────────────────────────────────────

node "Web 伺服器 / CDN" <<device>> as WebServer {
[客戶網站 HTML/JS/CSS] #..# (客戶 SPA)
[餐廳管理介面 HTML/JS/CSS] #..# (餐廳 SPA)
}

node "雲端後端" <<device>> as Cloud {
node "API 伺服器" <<executionEnvironment>> as APIServer {
artifact "backend-api.jar / main.exe" as BackendArtifact
}

node "PostgreSQL 伺服器" <<executionEnvironment>> as DBServer {
database "PostgreSQL 資料庫" as Postgres <<database>>
}
}

node "支付網關" <<external>> as Payment {
[支付 API] as PaymentAPI
}

node "通知服務" <<external>> as Notification {
[WebSocket / 推播 API] as NotifyAPI
}

' ── 關係 ─────────────────────────────────────────

WebServer --> Cloud : HTTPS (API 呼叫)

Cloud --> Payment : HTTPS (結帳)

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

' 檔案 → 組件實作（可選但清晰）
(Customer SPA) ..> BackendArtifact : <<呼叫>>
(Restaurant SPA) ..> BackendArtifact : <<呼叫>>

BackendArtifact --> Postgres : <<JDBC / SQL>>

BackendArtifact --> PaymentAPI : <<HTTPS 呼叫>>

BackendArtifact --> NotifyAPI : <<WebSocket / HTTPS>>

' 可選：若需要，可在資料庫上顯示協定
' BackendArtifact -right-> Postgres : <<JDBC>>

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

@enduml
Edit Plantuml in VPasCode



在 VPasCode 中編輯 Plantuml

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

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

總結 – 簡單食物訂購部署快速參考

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

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

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

🔗 參考清單