Components

The application currently runs on three main components:

• Desktop is the user interface that allows the user to interact with the system.
• Core is the background process that simulates the runs.
• Utils holds the shared configuration data definitions.

sequenceDiagram
  autonumber
    actor User
    participant D as Desktop
    participant C as Core

    User ->> D: start application
    D ->> D: tries loading default configs
    User ->> D: edits configurations
    User ->>+ D: starts run
    activate D
    D ->>+ C: submits configurations via IBlockchainBench
    activate C
    C --> D: notifies Desktop about progress of runs
    C --> D: returns results
    deactivate C
    deactivate D
    User ->> D: User can now inspect results

The Tests component (org.blockchainbench.tests for the core unit and regression tests, org.blockchainbench.ui.tests for the TestFX-driven UI tests) incorporates automated testing into the components. A Server component for remote, headless execution of the simulation exists as a bundle in the repository but is not part of the packaged product yet; see Server.

Bundles

The workspace is a set of Eclipse PDE bundles:

Bundle	Role	Page
org.blockchainbench.core	Simulation orchestration and the bridge to the Palladio simulator	Core
org.blockchainbench.utils	Shared domain models, the result data model, and configuration I/O	Utils
org.blockchainbench.desktop	JavaFX front end for configuring and observing runs	Desktop
org.blockchainbench.server	Headless batch runner	Server

A WebUI and a Client component appear in the architecture sketches as planned front ends; they are not part of the workspace yet.

How a run flows

1. A front end loads a list of SimulationConfig rows (from CSV) and one BaseConfig (from JSON).
2. It calls IBlockchainBench.submit(...), which returns a simulationId immediately and processes the runs on a background worker.
3. The worker initializes the standalone Palladio environment once per mode, then executes each run: build parameters, run the simulator, measure, and write a per-run JSON file.
4. The front end polls getSimulation(id) to observe progress and, when the group is finished, reads the collected result objects.

The full sequence, including the status state machine, is described in Simulation lifecycle.

Reading order

If you are new to the codebase, read the pages in this order:

• Overview — bundles, dependencies, threading, and the runtime context.
• Core — the orchestration engine and the simulator hierarchy.
• Utils — the data model shared by everything else.
• Simulation lifecycle — the end-to-end flow across all layers.
• Desktop and Desktop views — the interactive front end and its screens.
• Build and run — how to launch the applications and lay out the data.
• Glossary — the domain vocabulary used throughout.