我需要哪些UML图来概念化后台桌面应用程序？

我正在尝试开发一个web应用程序和一些桌面应用程序，所有这些应用程序都通过数据库或套接字tcp进行通信。这些桌面应用程序在后台运行，因此没有任何用例，web应用程序只供远程用户使用

而且，这些桌面应用程序通过DB与web应用程序通信，反之亦然

请问，哪些UML图可以帮助我概念化桌面应用程序的工作

我试图用开发图来概念化这件事，但是，我认为在报告中解释整个工作是不够的。不是吗

---

非常感谢

如果你阅读了用例图和参与者的理论，你会发现参与者（与用例交互的东西）可以是一个人或另一个系统

在这种情况下，由于您的应用程序是在后台运行的，因此必须由以下内容触发：由个人或作业调度器（=系统）触发。这意味着触发由参与者完成，因为参与者可以是个人或其他软件系统

---

这意味着你有一个用例（你的应用程序）和一个参与者（调度器或人员）。这样，您的后台应用程序可以在用例图中与系统的其他部分一起被描述为用例。

正如Rolf Schorpion所说，您仍然可以与系统参与者一起使用用例图。只需确保参与者是系统（或系统的一部分）的外部对象。典型的参与者可以是计时器（如果它是时间控制的）

此外，您还可以使用大量的UML图。从您发布的简短描述中，我推荐以下一组图表（至少这些是我要求您准备的图表，以便更好地理解您简要描述的系统）：

必填项：

组件图-显示系统的结构组织及其依赖关系（桌面应用程序、WEB应用程序、数据库都是组件）

部署图-显示网络组织、服务器以及之前定义的组件在服务器节点上的实际部署方式

序列图-显示组件之间的重要通信场景。您提到了TCP，因此可以使用一个或多个序列图进一步细化和显示它。如果有一个标准的通信模式，一个序列就足够了。否则，可以使用几个序列来覆盖所有重要的公共教育场景

可选：

类图-指定内部组件结构-设计（源代码的蓝图）。只有当每个组件都有一个复杂的设计时，我才推荐这个组件，值得为此付出努力。如果没有，保持模型与实际代码同步的成本可能会很高

状态分解图-如果一类组件显示的行为可以建模为一组离散状态（例如，打开、关闭、维修中、无序），则此图功能强大且高度推荐n

活动图-如果您有一些有趣的非平凡算法，或者只是想以顺序任务的形式显示整个系统逻辑，请使用活动图

这些是最常见的UML图。除此之外，您还有一些可以在某些特殊条件下使用的模型（例如，计时），但我相信您可以仅使用这些模型对几乎所有内容进行建模。用例远非UML建模的首选

---

如果你还有其他问题或疑问，尽管问吧

是的，你是对的，在我的例子中，它是由系统触发的，所以它是第二个参与者。但是在序列图中，我需要把这个参与者模拟成一个控制器吗？你可以在序列图中把这个参与者保持为一个参与者。你的后台进程可以看作是一个控制器。但我无法获取信息或询问参与者（如getStream（））？后台应用程序不是参与者，而是控制器。触发应用程序的系统或调度程序就是参与者。你从控制器而不是参与者那里获得信息。好的，那么我需要绘制在他启动时启动桌面应用程序的系统吗？组件图不是可选的？组件图和部署图之间有什么区别？每个图都是可选的，你可以在根本不建模的情况下编写代码。如果您想建模并正确执行，在我看来，在本例中，我将首先为组件建模。捕获系统的结构、模块和依赖项。部署图还显示了组件，但除此之外，它还显示了底层硬件结构以及组件在硬件节点上的分布方式。组件关注模块之间的依赖关系，部署关注模块在硬件上的分布。您的系统是明确分布的，所以depl。这是必须的。