sammo3332/netzwerk-tool

1. Project shape

- This is a Python desktop application, not a web service.

- The repo is split into a backend analysis pipeline and a PyQt-based frontend GUI, with a small entrypoint in start.py.

2. Main user flow

- Users upload one or more network dataset files in the GUI.

- The app runs analysis asynchronously in the background, then updates the interface with results.

- Results can be inspected per graph or aggregated across a dataset.

3. Frontend boundary

- frontend/gui_main.py is the GUI entrypoint.

- frontend/components/ contains the main UI building blocks: upload panel, toolbar, single-graph tab, dataset-analysis tab, analysis section, and visualization section.

- frontend/styles/default.css provides the app’s look-and-feel.

- The frontend is responsible for interaction, filtering controls, tab switching, and displaying tables/plots.

4. Backend orchestration

- backend/pipeline.py appears to be the central coordinator that connects file ingestion, conversion, analysis, and result handling.

- backend/file_converter.py and the files under backend/converters/ handle format-specific parsing/conversion.

- The backend is the main boundary between raw network files and normalized analysis-ready graph data.

5. Format-specific ingestion

- The converter layer is organized by dataset family: caida_converter.py, rocketfuel_converter.py, and sndlib_converter.py.

- The analyzer layer mirrors this structure with caida_analysis.py, rocketfuel_analysis.py, sndlib_analysis.py, and topology_zoo_analysis.py.

- This suggests the app treats different source ecosystems separately rather than forcing one generic parser.

6. Analysis subsystem

- backend/analyzers/ is where graph metrics and dataset-level statistics are computed.

- The README mentions metrics such as node count, edge count, density, centrality, connectivity, diameter, and efficiency.

- This layer likely produces both per-graph summaries and collections used by the dataset-analysis tab.

7. Data handling and persistence

- backend/data_processing.py likely normalizes, filters, or reshapes computed metrics before they reach the UI.

- backend/database_handler.py suggests some kind of storage or cached result handling, even if the app is primarily file-driven.

- backend/utils.py likely contains shared helpers used across conversion, analysis, and orchestration.

8. Visualization path

- The README says graph visualization is based on Matplotlib and is intentionally static.

- The frontend’s visualization section likely renders a selected graph after a row/file is opened from the analysis table.

- The app avoids interactive graph libraries such as VisPy to keep dependencies simpler and improve compatibility.

9. Two analysis views

- Single Graph Analysis focuses on individual uploaded files, with search, metric filtering, and direct opening of a graph visualization.

- Dataset Analysis aggregates metrics across collections such as TopologyZoo or SNDlib and shows grouped charts.

- This is an important architectural split: one path is per-file inspection, the other is cross-dataset comparison.

10. Concurrency and responsiveness

- The GUI is designed to stay responsive while analysis runs in the background.

- That means the backend work is likely executed off the main UI thread, with results pushed back into the interface when complete.

- For an architecture diagram, this is a key runtime boundary between UI events and long-running analysis.

11. Input formats and test data

- The tool is built around network graph files such as .graphml, .xml, .txt, and .cch.

- datasets-testen/ contains example inputs used for testing and demoing the app.

- The repository also includes tests for data processing, file conversion, and GUI behavior, showing the three main seams of the system.

12. External and non-core pieces

- .github/workflows/main.yml indicates CI automation, but it does not affect runtime architecture.

- The GitHub feedback link and release packaging mentioned in the README are distribution/support elements, not core app components.

- The core architecture remains: file upload → conversion → analysis → result filtering/display → static graph visualization.