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

Question

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

而且，这些桌面应用程序通过数据库与网络应用程序进行通信，反之亦然。

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

我尝试使用deploiement图来概念化这个东西，但是，我认为在报告中解释整个工作是不合适的。不是吗？

非常感谢！

Answer 1

如果您阅读了用例图和演员的理论，您将看到一个演员（与用例交互的东西）可以是一个人或另一个系统。

在这种情况下，由于您的应用程序在后台运行，因此必须由某人或作业调度程序（=系统）触发。这意味着触发是由演员完成的，因为演员可以是一个人或另一个软件系统。

这意味着你有一个用例（你的应用程序）和一个actor（调度程序或人）。通过这种方式，您的后台应用程序可以在用例图中与系统的其余部分一起描述为用例。

Answer 2

正如Rolf Schorpion所说，你仍然可以使用与系统性演员的用例图。只需确保actor是系统外部（或系统的一部分）。一个典型的演员可以是Timer（如果它是时间控制的）。

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

<强>强制性：

1. 组件图 - 显示系统的结构组织及其依赖关系（桌面应用，WEB应用，数据库是组件）
2. 部署图 - 显示网络组织，服务器以及以前定义的组件在服务器节点上的实际部署方式
3. 序列图 - 显示组件之间的重要通信方案。您提到TCP，因此可以使用一个或多个序列图进一步细化和显示。它有一个标准的通信模式，单个序列就足够了。否则，可以使用几个序列来涵盖所有重要的通信场景

可选

1. 类图 - 指定内部组件结构 - 设计（源代码的蓝色打印）。只有在每个组合中都有复杂的设计时，我才推荐这个，值得付出努力。如果没有，那么让模型与实际代码保持同步可能代价很高。
2. 状态贬值 - 如果一个组件类显示可以建模为一组离散状态的行为（例如ON，OFF，IN REPAIR，OUT OF ORDER），则此图非常强大并且非常推荐
3. 活动图 - 如果您有一些有趣的非平凡算法或只是想根据顺序任务显示整体系统逻辑，请使用activita图。

这些是最常见的UML图。除了你有几个更多的couls在某些特殊条件下使用（例如时间），但我确信你几乎可以只使用这些来模拟所有东西。用例远非UML建模的首选。

如果您还有其他疑问或疑问，请询问。