Car Dealers software VIN decoder application

Requirements Document – Conceptualization Continued - Central Dealership Server

Car dealers need to identify the cars they sell, buy and service. A Vehicle Identification Number, commonly abbreviated to VIN, is a unique serial number used by the automotive industry to identify individual motor vehicles. In 1981, the National Highway Traffic Safety Administration of the United States standardized the format. It required all over-the-road-vehicles sold to contain a 17-character VIN [1]. Car dealers software would enter in a VIN, check it's local database if not present contact a service to gain the information then store it locally for future retrieval. In this project we will simulate this with a client server mechanism where first the client checks it's local storage then contacts a server where the server processes the information and sends it back to the client.  By networking a series of Dealerships (for example Fields Dealerships) the dealerships could share the information rather than only checking their independent databases thru a common software.  Although the use cases can extend to many possible situations I am going to focus on one concrete use case.  I’ll meet the requirements of a single instance of registering a VIN, searching for a VIN and then obtaining a VIN.

Overall design is a Java based, multi-threaded, RMI Client-Server system with a Database.  Due to the nature of the BitTorrent type of peer-to-peer file sharing uploading and downloading system, each client will need to act as a server and client all registering with a centralized Dealership server.  Clients when joining into the . For my design I simulated the environment on my personal PC.  Code creation was done in a way that it could easily be ported and executed on a client server system.

In the project I want to implement items like interfaces, inheritance and even extend it to RMI execution.

Central Dealership Server


Central Dealership Server

Since the car dealerships in the case will act as peers to one another an RMI Callback methodology will be utilized.  Here the Car Dealership acts as a client needing Dealership services from the Dealership Server.

Car Dealership as a Client: Contacts the central Dealership server requesting a file in which it wants downloaded.  Since a service is being requested the Car Dealership is acting as a client.  In addition, each Car Dealership has an automatic updating mechanism so that if a file is modified the client will be updated.  If a file is modified or removed the Dealership Server will be notified and the database updated.  So when a new Car Dealershipcomes in the should get the updated version of the file

Car Dealership as a Server: Listens for a download request from another Car Dealership in the network. Provides services to other Car Dealerships in the system when the Dealership server directs other clients in the system to your node to provide a file sharing service.  Providing the ability to transfer a file contained on your Peer system to the requesting Car Dealership is the service the Peer will provide and at that point the Car Dealership is acting as a server. 

Possible Improvements and Design Tradeoffs: Adding in a SQL database, Adding in a GUI for the Client,Creating separate Stub classes for the Client.

Dealership Application


Dealer Requirements | Activity Diagram | Use Cases: Dealership Server Admin | Use Cases: Dealership Client | Car Dealership Client/Server Architecture | Class Diagram - VIN Retrieval System