Application design problem

Question

Hello. I am attempting to create a desktop standalone application for my mechanic. The application needs to store customer information, address information, vehicle information, repair history information, mechanic information, and job information. I have started creating data objects to represent these entities. I would like the front-end to be swing based or something else that would not take up alot of memory. The database will be a mysql database. The main purpose is to track jobs. A job will be created and an mechanic will be assigned to the job. It will track the hours worked and the type of job that was done. It will track the vehicle the job was done on and which customer the vehicle belongs to. The main view of the application should be a schedule of jobs that are marked visually showing if they are complete or not. I would like to have different views so that I can see a list of the most current customers. I would like to click on a customer and have thier last repair information be shown. This is a rough desc of what the application will do. Being a beginner I do not know where to start or what the design pattern should be. Can anyone suggests a life cycle perhaps that I should follow? As well as some guidelines to what I should code first? Again I have the data objects coded but what should I do next? Thank you.

Answer 1

The architecture question will depend a lot on how you foresee the program being used in the future. If it's likely to remain a single-user application, a desktop interface is the way to go. If it looks like several PCs will be accessing the data (perhaps one or two in the office and others in the workshop) then a web application may be the way to go.
A desktop application will probably be a 2-tier application (database in one tier, UI and business logic in the other). The web application will probably be a 3-tier application. One other factor that may influence your choice is that Swing is a much richer UI than is a web browser.
Next step is a class diagram, showing relationships between customers, vehicles, jobs and mechanics. This will give you a good overview of the system you're building. At the same time, write some use cases for the business functions � many of them will be the usual crud (create, read, update and delete).
Break the coding up into sub-systems and get each working before moving onto the next. For example, a suite of windows to collect, display and edit customers. Then do the same with the vehicles. There will be a link between vehicles and customers and some questions to think on (What happens if the customer sells the car and the new owner brings the car in for service? What happens if the customer gets custom plates for the car? ie. Is the plate number the primary key to the vehicle table?). Once customers and vehicles are stable, move onto the jobs.
As each sub-system is completed, you should have an executable that the customer can review and test. Get the customer to test to ensure you're on the right track. Watch out for scope creep though as the customer begins to see potential in areas that weren't apparent earlier in the project.