English
中文1. Introductions
According to the system requirement description, the aim of this project is to design a simple distributed system for chained electronic appliance shops. The system is supposed to be able to maintain stock information as well as customer information. Shopkeepers can access the stock information including name, type, model number as well as the availability of the products. And they can also add new customer, search a customer by the customer name and add new sales information to the existing customers’ purchase history. And the most important thing is that shopkeepers can access data from other branches’ computers.
In the remainder of this report, chapter 2 will show a description of the system architecture including the model I chose and the components of the system. Chapter 3 will talk about the design of the proposed system including textual description and UML diagrams. Chapter 4 is to point out some further issues in implementing this system. And the final chapter is to summarize and conclude this report.
2. System Requirement Analysis
2.1 Requirements
The five requirements that are necessary to gear-up the performance of the daily activities will be established in new system effectively and resourcefully. These requirements in different stores are achieved by making the different stores work in propinquity to each other. These five requirements are:-
- Speed of Response.
- Accuracy of Information.
- Cost-Effective Transaction.
- Low Overheads.
- Maintaining Service Standards.
2.2 Analysis
According to the given documents about the system requirement, the main operator of the system will be the shopkeeper. A shopkeeper can check all product information and he/she also can add a new customer into the system. Furthermore a shopkeeper can search a customer by his/her name. And a shopkeeper also can edit records of customers. In addition, via the network that connects each branch, a shopkeeper will also be able to access both the product information and customer information from other branches. To be more advanced, a shopkeeper can also place an order for a customer when the required product is out of stock.
However, there could be more functionalities included in this system, but as this is just a simplified version, it will not cover all functions. Only the functions mentioned above will be taken into account when designing the system.
2.3 Use cases
So, the system requirement can be described by the following use cases: check product information, add a new customer, search a customer, edit customer records and place an order. (See the figure below)
1.Check product information:
When the user selects to check some information of a product, he/she needs to input the product ID or name. The system will do the search on the local server first and then do it on other remote servers. Finally the system will show the search results.
2. Add a Customer:
When the user chooses to add a new customer, a customer registration form will be displayed and prompt the user to input customer details, such as name, gender, age etc. After entering all required information, the system will save the new customer information in the system.
3. Search a customer:
When the user chooses to search a customer, the system will ask the user to input the customer id or customer name as the search criteria, and then the system will check if the customer can be found in the local server, if the system can not find the customer on the local server, it will ask the user if he/she wants to search on other branches. Finally the system will display the search result including the customer’s personal data and purchase history data to the user.
4. Edit a customer: record
One customer record includes two parts: customer personal information and purchase history record. When the user chooses to edit a customer record, he/she can edit both customer personal information and the purchase history. And the user can get customer information from other branches and merge the local and remote customer information to have a refined customer record. After editing, the system will save the changes just made.
5. Place an order:
When one required product is temporally out of stock, the user can place an order for the customer. When the user chooses to place an order on a certain product, the system will ask the user to input the product information and the customer information and save them in the system.
2.4 System architecture
For distributed systems, there is a variety of models to choose from, such as client-server, peer to peer etc. As the client/server model is considered as the most popular way of implementing a distributed system, I will use client/server model to design this system. To make the system more efficient and scalable, it is designed to make the client as simple as possible; in other words, the presentation layer is on the client side, and the application and data layer are all on the server side. The figure below shows the overall architecture of the system:
As the figure shows, the client can call the public interfaces of the servers to complete any required operation. To be clear enough, we call the server directly linked to the client as local server and the remote one as remote server. A local server can get data from the local database to complete the operation required and also can invoke some public interface from a remote server to access remote data.
3. Design Implementation
3.1 System components
According to the designed system architecture, the system can be illustrated by the following figure.
As the figure shows, the top layer is the user interface of the system. And the application layer contains two parts: business logic part and classes. The bottom layer is the database of the system. The arrowed lines shows that the UI layer will invoke methods defined in business logic part to complete end-user operations, such as add new customer, edit customer record etc. And the business logic part will call methods defined in the entity classes (Product, Customer, Order…) to complete required operations. Also the entity classes need to access the system database to do any database related operation.
3.2 Designing with Class Diagram
The above figure is the class diagram of the core logic part of the system. It shows definitions of main classes and their relationship. The next section will briefly introduce how these classes interact with each other to complete the designed functionalities.
1. Check product information:
When the system is asked to perform a ‘check product’ operation, it will prompt the user to enter the product ID or product name. When the user interface layer gets the required parameters, it will invoke the checkProduct() method in the related business logic class, class CheckProduct and pass the parameters to the method. And then the checkProduct() method will call getProductDesc() method in class Product and pass the parameters to the method. The last parameter of getProductDesc() method is searchType, which is used to define whether the product search range includes other branches or not. Finally, the getProductDesc() method will call the connectDB(), doQuery(), getResult() methods and some other methods in class DBConnection to complete the search on the database. When a search on remote servers is requested, the setConnectionString() in class DBConnection can change the target database to access remote data.
2. Add a customer:
When “add new customers” request has been made, the system will prompt the user to enter all customer details. If the user interface get the right data, it will pass all data to setCustomerDesc() method in class Customer and then also invoke the addCustomer() method. And then the addCustomer() method will call connectDB() and doQuery() in class DBConection to update the database.
3. Search a customer:
When the system user interface gets the user input for customer search, it will pass the data to the getCustomerDesc() and getPurchaseHistory() methods. And then both methods will call the connectDB(), doQuery() and getResult() methods in class DBConnection to complete the operation. Also, when the getCustomerDesc() and getPurchaseHistory() methods are called, parameters can be set to notify the system if it’s a local search or remote search.
4. Edit customer record:
When the system is requested to edit a customer record, the user interface will pass all received data to the setCustomerDesc() and setPurchaseHistory() methods in the class Customer. And then both methods will call the connectDB(), doQuery() methods to finish the task. The system allows users to edit customer record either by manual input or remote retrieval.
5. Place an order:
When an order needs to be placed, the user interface will send all data to the placeOrder() method in class Order. And then the placeOrder() method will call connectDB() and doQuery() methods to add an order to the database.
4. Design Suggestions
As described above, the core logic of the system has been designed. However, due to the time limit, the design has not covered user interface design and database design. The suggestion on how to implement the proposed system can be described in the following aspects:
- Finish all remaining design: the user interface and database design need to be completed before implementing the system.
- Complete software functionalities: As end-user software, many additional functions need to be added on, such as system login, system administration and so on.
- Technologies and tools used in implementation: It is recommended to use java as the programming language and JBuilder as the main tool for system development. For database, MS ACCESS will be a good choice for this system.
5. Analysis & Alternative System options
This is the advance section of the brief which provides an overview of the current system and some of the alternative business system options that can be implemented to achieve the business goals that were set at the beginning of the project. The BSO1 is the business system option 1 which is also the current system that is proposed. This is the basic architecture with sufficient services. The difference between the architectures could be identified based on the services they provide. The services can be then kept in mind while generating the architecture for the chain of stores. The current proposed architecture provides the services as shown in the figure below.
5.1 Business System Option 1
This system option uses the distributed system architecture approach to address the issue of setting up the chain of stores. The technology used for implementing the design is JAVA with MS ACCESS or My SQL as the database management. The functions provided by the current system are shown in the figure below. All the customer details, product details and payment details are automatically handled. The current architecture system according to the table maintains the data concurrency for providing the exact information to all stores at any point of time. All the basic necessary information in this system is held electronically and efficiently. Although the system is able to manage the basic transactions but it still isn’t the best architecture. For this reason, based on the implementation of this system, some alternative architectures can developed based on the more significant and detail functions as provided in the table below.
5.2 Business System Option 2
This system as per the table shows that it not only provides the functions as provided by the current system but some additional features as well. The one of the major difference between the current system and this one is that this system identifies the customer’s interest. This means if a customer’s previous record shows that he has bought various kinds of game CDs then if in future any new game CD is released in market that customer will be noted first. Another, important feature that this architecture provides is that it monitors the products information and stock levels. This is important as it will remind the employees to get an idea that product needs to be replenished. The approach used by this architecture is the centralized network where central server has the database maintaining on it and all other systems are connected to it to form the client server architecture. This system also offers the business 2 consumer management which makes the system more robust and powerful. It also provides the web interface which will provide online shopping facility for the customers.
5.3 Business System Option 3
This system provides all the functions mentioned in the table. It uses J2EE with the ORACLE database management system to provide back and front end connectivity. It also uses the service oriented architecture which focuses on the services of the system as well. The BSO 3 provides the value added functionalities which makes it even more powerful and efficient. The system also provides an excellent search facility for which it can use LUCENE, which is wonderful indexing system. The indexing will provide the faster search and retrieving facilities thus making system more significant and efficient. This option also generates any ad-hoc reports needed for the customers or for other general purposes.
The advantages of using either business system option 2 or 3 are discussed below in detail.
This is all done firstly, by the making some default queries which will perform these activities when needed to execute and secondly, by placing indexes on appropriate database tables which will help in searching and retrieving data efficiently. The architecture option 3 will prove useful in this case as it provides the good indexing technique.
2) Accuracy of Information: – The sharing of information between different stores at very high speed is of no use if the information is inaccurate. So, it’s essential to achieve the consistency in data. For instance, suppose the product availability in one store shows true and the customer is given the information. But when the customer reaches the branch and finds out because of the information inconsistent he was given the wrong information and the product is out of stock. This will loose the customer which means loss in the business. So, when the data is changed in one database at one store it should be automatically changed in every store’s database. These kinds of problems will be resolved by creating views. So, when the database will be updated, all its instances or views will be automatically updated thus achieving the data accuracy.
3) Cost-Effective Transactions: – This is important from customer’s point of view as it will help in making a good customer relationship.
This requirement will be solved firstly, by giving products at lower price via internet making customers place order online thus evading use of paper based work and avoid the problems of slow transactions and inaccurate data which results in cost-effective transactions. Secondly, because of excellent information sharing at great speed and accurate data exchange, the transactions within the system will be resourcefully and economically executed thus resulting in cost-effective transactions.
4) Low Overheads: – The system is built in such a way that it has minimum overheads. Each department will have necessary information required for executing the transaction thus making system more efficient. For instance, one store branch will no longer have to wait for the product stock details of the different branch store. All the stores will have enough information needed for them for smooth working flow of transactions without any complications.
The system is also proposed in such a way that there is only one point of data entry and the duplication in data entry is avoided e.g. views-updation technique and thus saving the efforts and work load of the users inside the boundary.
5) Maintaining Service Standards: – Store employees might require appropriate on-screen helps information as well as proper documentation on how to use the system. Ensure appropriate training is given to users of the proposed system before implementation. Also users of the store will need easily comprehensible document for the operation of the system in order to deal with after-training user problems. The easy simple FAQ’s will also be presented in help menu for future help for both users inside and outside the system boundary.
However, the major disadvantage about options 2 and 3 in relation to the current architecture may be that both these architectures are expensive to implement. Although, the cost-effective transactions can be implemented but initial investment and the maintaining investment would be much more than the current system. An important and necessary change that needs to be implemented in the current system is shown in the figure below. This means the customer has as access to the store through the web interface as well. This will allow profits to both the parties as for the customer it as easy to shop 24×7 and the store can also sell their products 24×7 without actually opening the store. Another different architecture diagram can be of structure as shown in figure 1 which uses the central database server/client architecture.
The security issues in this architecture will be resolved by providing secure transactions. The customers will be provided with the unique username and password which will make them authenticate the system.
Because of the online screen help and easy simple FAQs most of the faults and queries will be easily solved by the users of the system itself.
The new architecture is an extension and enhancement to the legacy system. So, the implementation of the new system will definitely will resolved the usage of the legacy system.
6. Conclusion
This report has briefly discussed the design of the proposed chained stores system. At the beginning of the report, a textual description of the system requirement analysis has been shown. And then the use cases of the system have been introduced by some textual description and a use case diagram. And then the system architecture, which is client/server architecture, has been illustrated with a system architecture diagram. The later chapter has included description of system components and design of classes. Finally, some suggestions and recommendations have been given out in chapter 4.
From this course work, I have understood the concept of distributed systems as well as some issues of how to build a distributed system.
