Hydrographic Network UML Diagrams#
Scope#
These diagrams document the software architecture around the hydrographic network concept introduced to unify:
the loaded reference network from
data.hydrography,the DEM-derived generated network from
geographic.river_network,the persisted run features used later by display and comparison layers.
They focus on responsibilities, runtime handoffs, and the difference between canonical concepts and technical preprocessing bundles.
Code map#
hydromodpy/spatial/geographic/core/hydrographic_network.py: canonical network classes and naming contract.hydromodpy/spatial/geographic/core/hydrographic_network_comparison.py: comparison result and geometric metrics.hydromodpy/spatial/geographic/core/river_network.py: DEM-derived preprocessing outputs (RiverNetworkProducts).hydromodpy/spatial/geographic/core/derived_features.py: geographic bundle that carries canonical network roles.hydromodpy/workflow/steps/prepare_solver.pyandhydromodpy/spatial/geographic/store_ingestion.py: persistence into the catalog.hydromodpy/results/run.py: read facade and comparison accessors.hydromodpy/display/figures/hydrographic_network*.py: standalone and comparison figures.
Recommended reading path#
hydromodpy/spatial/geographic/core/hydrographic_network.pyhydromodpy/spatial/geographic/core/river_network.pyhydromodpy/spatial/geographic/core/derived_features.pyhydromodpy/workflow/steps/prepare_solver.pyandhydromodpy/spatial/geographic/store_ingestion.pyhydromodpy/results/run.pyhydromodpy/display/figures/hydrographic_network.pyandhydromodpy/display/figures/hydrographic_network_comparison.py
Class Diagram#
Use this diagram when the main question is: “which class is canonical, which one is technical, and which one is only a comparison result?”
Runtime Component Diagram#
Use this diagram when the main question is: “where does the network come from, how is it persisted, and who consumes it?”
End-to-End Sequence Diagram#
Use this diagram when the main question is: “what is the order of operations from loading/generation to comparison?”
Availability Activity Diagram#
Use this diagram when the main question is: “what happens when only one role exists, or when neither role exists?”
Persistence And Run API Sequence Diagram#
Use this diagram when the main question is:
“how do the persisted features reach the Run API, and what errors should a
developer expect when a role is missing?”
Persistence And Run API Notes#
From a developer point of view, the most important operational split is:
prepare_solver.pypersists the loaded reference role whendata.hydrographyproduced one usable vector network.store_ingestion.pypersists the generated role when the geographic preprocessing produced one usable DEM-derived network.SimulationCatalogstores those features under canonical names only.Rundoes not guess. It first exposes the stored roles throughavailable_hydrographic_network_roles()andhas_hydrographic_network(...), then only enables comparison if both roles are present.
This means the runtime contract is intentionally asymmetric:
persistence is tolerant and simply skips missing roles,
reading one missing role raises a clear
KeyError,comparing two roles when one is absent raises a clear
ValueError,figure availability follows the same rule through
run.display_capabilities.
Which UML Diagrams Are Worth Maintaining?#
For this topic, the highest-value diagrams are:
A class diagram for the distinction between
HydrographicNetwork,HydrographicNetworks,HydrographicNetworkComparison, andRiverNetworkProducts.A component diagram for the source -> canonical object -> persistence -> consumer chain.
A sequence diagram for the end-to-end runtime path, including the “missing role” branch.
An activity diagram for the availability branches and output gating.
A developer-facing sequence diagram for persistence and
Runbehavior.
These three diagrams answer the most common maintenance questions:
where should a new field live?
where should a conversion happen?
when should a role be present or absent?
who is allowed to compare or display the networks?
Lower-value diagrams for this topic are:
state-machine diagrams, because these objects do not have a rich internal lifecycle;
deployment diagrams, because there is no interesting multi-node deployment question here;
exhaustive inheritance diagrams, because the hydrographic-network stack is composition-oriented rather than inheritance-heavy.
If more detail is needed later, the next useful addition would be one small package-level component diagram focused only on:
prepare_solver.pystore_ingestion.pyRunthe display figure registry
the comparison export orchestrator