THE RULES BEHIND THE SOFTWARE
HRIS
Connect staff availability and driver qualifications to store delivery planning.
PEOPLE & TIME
contracts
VEHICLE & LOAD
Type + capacityCode-native explanation of the implementation. Illustrative data.
- CONTEXT
- University coursework
- MY ROLE
- Sole developer
- TIMELINE
- 2023
- EVIDENCE
- Source reviewed · illustrative diagrams
AT A GLANCE
The dispatch handshake
An academic Java desktop system joins employee administration and weekly shift scheduling with deliveries, truck selection and driver assignment. Its most useful engineering story is the boundary between two business areas: HR provides availability, while delivery planning checks driver qualifications and reports assignments back.
My contribution +
I developed this project as university coursework. This case covers my implementation and the engineering decisions behind it.
WHAT THE SYSTEM HANDLES
The interesting parts.
Schedule around actual constraints
Employees submit availability; HR assigns qualified staff to stores and roles, confirms shifts and manages weekly schedules.
Implementation details
- Role/store certification checks before shift assignment.
- No two shifts on a day and a six-shift weekly limit in the controller.
- Shift confirmation requires a shift manager.
- Employee removal is refused when future shifts remain.
Find a driver and truck that fit
Delivery planning selects available regular or refrigerated trucks, checks license weight/type permissions and asks HR for drivers available over the trip interval.
Implementation details
- Truck selection reserves an available matching vehicle.
- Driver selection combines HR time availability with local busy state and license compatibility.
- Successful driver assignment is reported back through HRIntegrator.
Handle changes during a delivery
Delivery stops are grouped by origin and delivery zone. A journey tracks visited stops and invokes replanning when a measured load exceeds the truck limit.
Implementation details
- Replanning can try a replacement truck/driver, remove a stop, cancel the form or reweigh.
- Cancelled undelivered stops return to the pending set.
- Origin/zone grouping is implemented; route-distance optimization is not established.
One business system, two interfaces
CLI and Swing screens use shared service/business layers, backed by SQLite data-access classes for employees, shifts, trucks and delivery records.
Implementation details
STRUCTURE & JUDGMENT
How the parts fit.
Swing + CLI
Separate presentation paths
→ HR facade + scheduling / Delivery planningHR facade + scheduling
Employees, roles, stores, weekly shifts
→ Integration contracts / SQLite data accessIntegration contracts
HRIntegrator · DeliveryIntegrator · DriverSaver
Delivery planning
Stops, forms, drivers, trucks
→ Integration contracts / SQLite data accessSQLite data access
HR and delivery DAOs
- Java 17
- Swing
- CLI
- SQLite / JDBC
- Maven configuration
- JUnit 5
- Mockito
Use explicit contracts between staffing and delivery
Three small interfaces expose availability, assignment, scheduled arrivals and driver registration without requiring the caller to own the other subsystem’s data structures.
WHY IT MATTERSA delivery’s staffing dependency is visible and testable. This benefit is inferred from the implementation, not a quote from the author.
Make overload handling a domain operation
WeightMeasurer and TripReplanner interfaces feed DeliveryForm’s load checks, with explicit remove-stop, cancel and reweigh actions.
WHY IT MATTERSThe exceptional case is modeled alongside the normal trip, rather than reduced to an unstructured UI error.
Keep presentation separate from stored business records
Swing/CLI choices share HR and delivery services; DAOs use a SQLite connector, whose query/update helpers bind supplied parameters.
WHY IT MATTERSBusiness behavior can serve multiple presentation paths and persist beyond the in-memory objects. Some controllers remain singletons and coupled to concrete classes, so this is layered design, not a perfectly isolated domain.
Scope, limitations & what I would revisit
- Source-only evidence. No fresh execution, deployment or current test-pass claim.
- The startup loader resets HR tables and loads example records; the executable should be treated as an archived academic demonstration, not an operated HR database.
- Destination staff availability is queried but its rejection branch remains TODO; do not claim unstaffed destinations are prevented automatically.
- Default startup accesses args[0] and args[1] before checking argument count. Build/source layout and packaged artifacts are archival, not verified current instructions.
- Tests include meaningful driver/HR integration cases alongside some empty test methods. Presence of tests is not proof of full coverage or passing behavior.