我正在嘗試為我的專案制作用例圖，后端將使用 Django rest 框架制作，前端使用 react，我的問題是如何以正確的方式對這種情況進行建模，我應該為前端建模并將后端表示為演員或相反，因為我正在考慮將移動應用程式作為第二個前端？
uj5u.com熱心網友回復：
這里的正確答案是第 1 號業務分析師的標準答案：視情況而定。
問題是 - 你想建模什么以及為什么。然后 - 什么是正確的工具（圖表）來做到這一點。
用例圖的目標是顯示系統將提供哪些功能。現在可以將系統視為一個整體，在這種情況下，您可以在不描述系統內部組織方式的情況下顯示功能（這是最常見的場景，并且很可能是在您的案例中使用用例圖的最佳方式 - 但確實如此沒有顯示有 FE 和 BE 的事實，請注意這種型別的圖表并不是最適合這樣做，所以請繼續閱讀）。
您也可以將 BE 視為系統本身（這很有意義，尤其是當您準備無頭 API 并將 BE 與 FE 真正分開時；當您的 BE 和 FE 團隊完全分開時更是如此）。在這種情況下，FE 將成為參與者（就像其他可以與您的 BE 互動的系統一樣）。顯然 FE 可以以相同的方式處理（即被視為以 BE 為參與者的系統），但通常沒有這樣做的理由。
話雖如此，如果您想描述 BE 和 FE 之間的區別，您應該考慮其他型別的圖表。請記住，用例圖是動態圖，系統的內部結構是靜態的，所以顯然它應該是靜態圖之一。一個專門用于顯示系統內部結構的組件圖是組件圖，它很可能最適合指示 FE 和 BE 的存在（可能具有更詳細的細節，例如現有的微服務）。
另一方面，如果您想展示正在使用的特定技術，部署圖可能是您的最佳選擇。它允許顯示實際的運行時環境、工件及其技術。
請記住 - 使用一種型別的圖表，甚至更糟糕的是一種圖表來顯示所有內容通常是一個壞主意，也是新手經常犯的錯誤。比那更聰明。
uj5u.com熱心網友回復：
用例是關于一組具有可觀察結果的行為，該結果對參與者有價值。他們不應該關心系統的內部：
用例定義主題的提供行為，而不參考其內部結構。
因此，原則上你不應該關心前端和后端的區別，而應該關注系統的參與者目標。
在用例圖中，您需要關心后端的唯一情況是前端將是一個獨立的應用程式，它本身就有價值，但可以與代表外部獨立的參與者互動系統。（更多在這里）
轉載請註明出處，本文鏈接：https://www.uj5u.com/qianduan/450621.html