系统间关系的 UML 包图
UML package diagram for relationship between systems
我有这个简单的图表，它不遵循任何类型的 UML 图。它的目标是展示我们解决方案的所有部分，以及它们之间的关系。
图中：网页抓取工具抓取部分网站的数据，存入数据库。 Web 应用程序接收过滤器选项并使用 Rest API 实现它，returns 一些数据以 xlsx 和 csv 格式导出。 API 使用由网络抓取工具填充的数据库。
我需要使用 UML 使用上面突出显示的过程制作一个新图表。我有一个使用包图的建议，所以我做了这个版本：
编辑： 图中：Fonts -> Web Scraper -> Database -> Api(Filters(过滤器类型)) -> Front end (results , 搜索选项) -> 用户
封装图的制作方法正确吗？对于这种情况，我找不到类似的示例或特定规则。
包是满足您需求的正确建模工具吗？
Packages 是命名空间，旨在构建模型。因此，包图并不表示具有数据流（动态行为）的过程。包之间的关系是名称空间关系，例如 «imports» 和 «merges» 以及依赖关系。
您的包图肯定显示了您使用嵌套包的设计的一些有效分解。但是您通常不会代表用户 (usario)，或来自数据库 (Banco de dados).
UML 中有哪些更好的替代方案？
您的初始图表显示在一张图片中，使用一些流程图符号，非常不同的东西：
- 字体、过滤器或文件等对象的概念类
- 网络爬虫、数据库、前端、后端等组件，
- 对象流，例如为后端查询的数据库提供数据的网络爬虫，或前端供应过滤器与提供数据的后端之间的交互。
如果您想在 UML 中表示它，您需要阐明重点，因为 UML 需要一定的精度，因为它将结构和行为分开。答案将取决于您要显示的内容：
- 流程和数据的流动？使用 activity diagram（行为）。这非常适合显示从源到最终结果的流程，但不那么容易显示所涉及的系统部分。
- 组件之间的关系？使用 component diagram（结构）。这非常适合识别组件、这些组件如何嵌套以及它们的接口如何连接。但它没有显示所有这些发生的顺序。
- 组件之间的交互？使用 communication or sequence diagrams（行为）。在这里您可以看到组件以什么顺序交换什么，但看不到组件的结构。
自发地，我会选择组件，因为我的印象是它主导了您的原始图表。但最后，你可能会用不同的图表来展示不同的方面。
其他选择
如果您正在寻找一个单一的图表来结合原始图表的不同想法，而不是 UML，您可以考虑 C4 model 个图表。
它不如 UML 精确，但对于传达系统架构的全景图非常方便。 Paticula 中的 C4 上下文图和 C4 容器图允许显示系统的主要组件，以及它们之间的一些高级关系（包括数据流）。
好消息是 C4 依赖 UML 来对已识别的组件进行更详细的设计。
我有这个简单的图表，它不遵循任何类型的 UML 图。它的目标是展示我们解决方案的所有部分，以及它们之间的关系。
图中：网页抓取工具抓取部分网站的数据，存入数据库。 Web 应用程序接收过滤器选项并使用 Rest API 实现它，returns 一些数据以 xlsx 和 csv 格式导出。 API 使用由网络抓取工具填充的数据库。
我需要使用 UML 使用上面突出显示的过程制作一个新图表。我有一个使用包图的建议，所以我做了这个版本：
编辑： 图中：Fonts -> Web Scraper -> Database -> Api(Filters(过滤器类型)) -> Front end (results , 搜索选项) -> 用户
封装图的制作方法正确吗？对于这种情况，我找不到类似的示例或特定规则。
包是满足您需求的正确建模工具吗？
Packages 是命名空间，旨在构建模型。因此，包图并不表示具有数据流（动态行为）的过程。包之间的关系是名称空间关系，例如 «imports» 和 «merges» 以及依赖关系。
您的包图肯定显示了您使用嵌套包的设计的一些有效分解。但是您通常不会代表用户 (usario)，或来自数据库 (Banco de dados).
UML 中有哪些更好的替代方案？
您的初始图表显示在一张图片中，使用一些流程图符号，非常不同的东西：
- 字体、过滤器或文件等对象的概念类
- 网络爬虫、数据库、前端、后端等组件，
- 对象流，例如为后端查询的数据库提供数据的网络爬虫，或前端供应过滤器与提供数据的后端之间的交互。
如果您想在 UML 中表示它，您需要阐明重点，因为 UML 需要一定的精度，因为它将结构和行为分开。答案将取决于您要显示的内容：
- 流程和数据的流动？使用 activity diagram（行为）。这非常适合显示从源到最终结果的流程，但不那么容易显示所涉及的系统部分。
- 组件之间的关系？使用 component diagram（结构）。这非常适合识别组件、这些组件如何嵌套以及它们的接口如何连接。但它没有显示所有这些发生的顺序。
- 组件之间的交互？使用 communication or sequence diagrams（行为）。在这里您可以看到组件以什么顺序交换什么，但看不到组件的结构。
自发地，我会选择组件，因为我的印象是它主导了您的原始图表。但最后，你可能会用不同的图表来展示不同的方面。
其他选择
如果您正在寻找一个单一的图表来结合原始图表的不同想法，而不是 UML，您可以考虑 C4 model 个图表。
它不如 UML 精确，但对于传达系统架构的全景图非常方便。 Paticula 中的 C4 上下文图和 C4 容器图允许显示系统的主要组件，以及它们之间的一些高级关系（包括数据流）。
好消息是 C4 依赖 UML 来对已识别的组件进行更详细的设计。