Car Dealership Manager

A dealership as connected records

Vehicles, customers, brokers and sales each have their own behaviour, but the application must connect them without duplicating business rules across screens.

The application gives dealership staff one workspace for adding cars, maintaining inventory status, viewing customer and broker directories, and recording sales that connect all four record types.

From incoming inventory to completed sale

A sale is more than an isolated record: it links a car, buyer, broker and final price, marks the selected vehicle as sold, assigns the customer to the broker and records each change in the event log.

• Add vehicles with model, year, colour, packages and price
• Track six inventory states from creation to sold
• Browse inventory, sales, brokers and customers
• Record a sale across car, customer and broker IDs
• Save or restore the complete dealership workspace

Domain boundaries before screens

The codebase separates model, UI and persistence packages. Dealership acts as the aggregate for cars, brokers, customers and sales; each record type owns its own state while cross-record business rules remain centralized in the dealership model.

The Swing and console entry points operate on the same domain objects, while the Writable contract, JsonReader and JsonWriter keep file serialization outside the interface layer. This organization keeps the model usable independently of either presentation path.

A modular tab-based workspace

The Swing interface groups daily operations into focused tabs. Event logging and JSON persistence provide continuity, while the domain model remains usable independently of the interface.

Home handles load and save actions; Inventory presents cars and status editing; Sale links the records needed for a transaction; Directory exposes brokers and customers. A separate console application provides the same core workflow without the graphical layer.

State that survives the session

The full dealership aggregate is serialized with org.json to data/dealership.json. The reader reconstructs cars, brokers, customers and sales, while restored car IDs advance the next identifier to reduce collisions after loading.

A singleton EventLog records meaningful model changes such as adding cars, updating status, assigning customers and completing sales. The GUI prints the accumulated log when its window closes, providing a chronological account of the session.

Design that can be inspected

JUnit tests, Checkstyle and a documented UML model make the architecture visible and support disciplined iteration.

Thirty-nine JUnit 5 tests cover the domain model, singleton event log and JSON reader/writer against both general and empty fixtures. The UML diagram records class responsibilities across the tabs, aggregate model, persistence layer and event system.

• Replace integer car states with a CarStatus enum
• Introduce a shared ID generator
• Extract common broker and customer fields into Person
• Move broker-customer links from IDs to managed object associations

A Java 11 desktop application

Compile the project with JDK 11 or newer and the libraries in lib. Run ui.DealershipUI for the Swing application or ui.Main for the console version; Windows users replace the colon in the classpath with a semicolon.