UML package diagram for relationship between systems

I have this simple diagram, it doesn't follow any type of UML diagram. Its goal is to show all the parts of our solution, and how they're related.

In the image: the web scraper scraps the data in some websites and stores it in the database. The web application receives filter options and implement it using a Rest API that returns some data to be exported in xlsx and csv. The API uses the database populated by the web scraper.

I need to make a new diagram with the highlighted process above, using UML. I had a suggestion to use a package diagram, so I made this version:

Edit: In the image: Fonts -> Web Scraper -> Database -> Api(Filters(type of filters)) -> Front end (results, search options) -> User

Is it the right way of making a package diagram? I couldn't find a similar example or specific rules for this case.

Are packages the right modeling tool for your needs?

Packages are namespaces and aim to structure a model. A package diagram therefore does in not represent a process with data flows (dynamic behavior). The relations between packages are namespace relations such as «imports» and «merges» and dependencies.

Your package diagram certainly shows some valid decomposition of your design with nested packages. But you would normally not represent users (usario), or flows of data (dados) coming from a database (Banco de dados).

What are the better alternatives in UML?

Your initial diagram shows in one picture, using some flowcharting symbols, very different things:

• conceptual classes of objects such as fonts, filters, or files
• components such as web scraper, the database, front-end, back-end,
• flows of objects like the webscraper that feeds the database that is queried by the backend, or interactions between freont-end suppliying filters and back-end that provides data.

If you want to represent this in UML you need to clarify the focus, because UML requires some precision since it separates structure and behavior. The answer will depend on what you want to show:

• the flow of processes and data? Use an activity diagram (behavior). This is perfect to show the flow from the source to the end-result, but not so easily the parts of the system that are involved.
• the relationship between components ? Use a component diagram (structure). This is perfect to identify the components, how these are nested, and how their interfaces are connected. But it does not show the order in which all this happens.
• the interaction between components ? Use communication or sequence diagrams (behavior). Here you see what the components exchange in what order, but not so well how the components are structured.

Spontaneously, I'd go for components, since I have the impression that this dominates your original diagram. But in the end, you may use different diagrams for showing the different aspects.

Other alternatives

If you're looking for a single diagram to combine the different thoughts of your original diagram, alternatively to UML, you could consider C4 model diagrams.

It's less precise than UML, but very convenient for communicating the big picture of a system architecture. The C4 context diagram and the C4 container diagram in paticula allow to show the system's main components, and some high-level relations (including data flows) between them.

The good news is that C4 relies on UML for the the more detailed design of the identified components.