在用例图中对前端和后端建模
Modeling frontend and backend in a use case diagram
我正在尝试为我的项目制作一个用例图，后端将使用 Django rest 框架制作，前端将使用 React，我的问题是如何以正确的方式对这种情况进行建模，我应该为前端建模并将后端表示为演员还是相反，因为我正在考虑将移动应用程序制作为第二前端？
这里的正确答案是 Business Analyst 1 的标准答案：这取决于。
问题是 - 您想要建模什么以及为什么。那么 - 什么是正确的工具（图表）来做到这一点。
用例图的目标是显示系统将提供的功能。现在可以将系统视为一个整体，在这种情况下，您可以在不描述系统内部组织方式的情况下展示功能（这是最常见的场景，最有可能是在您的案例中使用用例图的最佳方式 - 但它确实如此没有显示具有 FE 和 BE 的事实，请注意，这种类型的图表并不是真正最适合这样做的，因此请继续阅读）。
您也可以踩例如BE 作为系统本身（特别是当您准备无头 API 并且真正将 BE 与 FE 分开时，这很有意义；当您的 BE 和 FE 团队完全分开时更是如此）。在这种情况下，FE 将成为一个参与者（就像其他可以与您的 BE 交互的系统一样）。显然 FE 可以以相同的方式处理（即被视为 BE 是演员的系统），但通常没有理由这样做。
话虽如此，如果你想描述BE和FE的区别，你应该考虑其他类型的图表。请记住，用例图是一个动态图，系统的内部结构是静态的，所以显然它应该是静态图之一。专门用于显示系统内部结构的一个是组件图，它最有可能最能达到指示 FE 和 BE 存在的目的（可能具有更高级别的细节，例如现有的微服务）。
另一方面，如果您想展示正在使用的特定技术，部署图可能是您的最佳选择。它允许显示实际的运行时环境、工件及其技术。
请记住 - 捆绑使用一种类型的图表，或者更糟糕的是一种图表来显示所有内容通常是一个坏主意，也是新手经常犯的错误。比那更聪明。
Use-case 是关于一组具有对参与者有价值的可观察结果的行为。他们不应该关心系统的内部结构：
UseCases define the offered Behaviors of the subject without reference to its internal structure.
因此，原则上不要在意front-end和back-end的区别，而要关注actor与系统的目标。
您唯一关心 use-case 图表中的 back-end 的情况是 front-end 是一个独立的应用程序，在其上有价值拥有，但可以与代表外部 独立 系统的参与者交互。 （更多here）
我正在尝试为我的项目制作一个用例图，后端将使用 Django rest 框架制作，前端将使用 React，我的问题是如何以正确的方式对这种情况进行建模，我应该为前端建模并将后端表示为演员还是相反，因为我正在考虑将移动应用程序制作为第二前端？
这里的正确答案是 Business Analyst 1 的标准答案：这取决于。
问题是 - 您想要建模什么以及为什么。那么 - 什么是正确的工具（图表）来做到这一点。
用例图的目标是显示系统将提供的功能。现在可以将系统视为一个整体，在这种情况下，您可以在不描述系统内部组织方式的情况下展示功能（这是最常见的场景，最有可能是在您的案例中使用用例图的最佳方式 - 但它确实如此没有显示具有 FE 和 BE 的事实，请注意，这种类型的图表并不是真正最适合这样做的，因此请继续阅读）。
您也可以踩例如BE 作为系统本身（特别是当您准备无头 API 并且真正将 BE 与 FE 分开时，这很有意义；当您的 BE 和 FE 团队完全分开时更是如此）。在这种情况下，FE 将成为一个参与者（就像其他可以与您的 BE 交互的系统一样）。显然 FE 可以以相同的方式处理（即被视为 BE 是演员的系统），但通常没有理由这样做。
话虽如此，如果你想描述BE和FE的区别，你应该考虑其他类型的图表。请记住，用例图是一个动态图，系统的内部结构是静态的，所以显然它应该是静态图之一。专门用于显示系统内部结构的一个是组件图，它最有可能最能达到指示 FE 和 BE 存在的目的（可能具有更高级别的细节，例如现有的微服务）。
另一方面，如果您想展示正在使用的特定技术，部署图可能是您的最佳选择。它允许显示实际的运行时环境、工件及其技术。
请记住 - 捆绑使用一种类型的图表，或者更糟糕的是一种图表来显示所有内容通常是一个坏主意，也是新手经常犯的错误。比那更聪明。
Use-case 是关于一组具有对参与者有价值的可观察结果的行为。他们不应该关心系统的内部结构：
UseCases define the offered Behaviors of the subject without reference to its internal structure.
因此，原则上不要在意front-end和back-end的区别，而要关注actor与系统的目标。
您唯一关心 use-case 图表中的 back-end 的情况是 front-end 是一个独立的应用程序，在其上有价值拥有，但可以与代表外部 独立 系统的参与者交互。 （更多here）