Sunday, November 11, 2012

Object oriented design for an online auction site

Object oriented design for an online auction site

Typical set of operations on the online auction site from the user perspective are

  • Users should register themselves and sign in to participate or start auctions in the online auction site. 
  • A user can create a new item category to be auctioned in the site or else he can search ongoing auctions on the item and participate in one or more of these auctions simultaneously. 
  • Upon participating in auction he/she can place the bids.
  • He/she can come out of the auction at any time.
  • If he wins the auction by placing the highest bid, he has to pay the bid price to the payment sub system
  • If he is the owner of the auction which was complete with a winner, he should send the items to the delivery sub system.
Based on the above description the main components of the system would be
User -> can act as bidder/seller
Item -> Things which are sold and bought in the system
Auction -> Process in which seller wants to sell the item
Bid -> users quotes for the item being sold
Auctioneer -> one who oversees the process of start, stop and conducts the whole process
PaymentHandler -> component which accepts the payments from winning bidder and transfers the payment to the seller


Based on the above description this is the class diagram of the system:



Saturday, November 10, 2012

Object oriented design for a library to borrow and renew books

Object oriented design for a library to borrow and renew books

A typical library has a set of books which the users can borrow for a certain period of time and return back. Users may choose to renew the return date if they feel they need to more time to read the book. We are trying here to design an online library.

The typical user actions with this online library would be

  •  sign in/register
  •  search books
  •  borrow books
  •  renew the return date for any of the books borrowed
  •  view his profile(check his details, list of books he borrowed )

The online library should support all the above actions. It must keep track of the different books in the library currently available for users to borrow and also the books already borrowed bu users. Put it simply the inventory should be managed.

Going through the above description we can think of these components in the system:

  1. User
  2. Book
  3. BorrowTxn -> record for the event for book b is borrowed by user u
  4. InventoryManager -> manages the books in the library. Adds new books, remove books and respond to book search requests
  5. LibraryManager-> Allows user interaction with the library like logging in, borrowing, renewal and return.

Below is the class diagram which depicts how these components inter-operate 



The Library Manager(LibManager) interacts with the inventory manager for responding to user search queries. Each borrow operation would result in the creation of a BorrowTxn which encapsulates the book details, borrowing user details and the return date. The inventory state is updated accordingly(i.e. the borrowed book is no longer available for borrowing). Similarly when a book is returned the inventory state is updated.

When the book return date is renewed the inventory state is not changed but the borrow transaction is updated accordingly.

Object Oriented design for Elevator in a multi-storied apartment

Object Oriented design for Elevator in a multi-storied apartment

Below is the design for an elevator in a multi-storied building.

A typical lift has buttons(Elevator buttons) inside the cabin to let the user who got in the lift to select his/her desired floor.Similarly each floor has buttons (Floor buttons) to summon the lift to go floors above and floor below respectively. The buttons illuminate indicating the request is accepted. And the lift reaches the requested floor the button stops illuminating.

Use cases:
User

  • presses the floor button to summon the lift
  • presses the elevator button to make the lift move to the desired floor


Floor Button/Elevator Button

  • illuminates when pressed
  • places a elevator request when pressed
Elevator
  • Moves up/down as per instruction
  • Opens/closes the door
Each button press results in an elevator request which has to be served. Each of these requests is tracked at a global place. ElevatorRequests, the class which stores elevator requests can use different strategies to schedule the elevator requests. The elevator is controlled by a controller class which we call ElevatorController. The elevator controller instructs the elevator what to do and also can shutdown/start up the elevator of the building. The elevator controller reads the next elevator request to be processed and serves it. 







Button is abstract class defining common behavior like illuminate, doNotIlluminate. FloorButton, ElevatorButton extend Button type and define placeRequest() which is invoked when the button is pressed. Both the floor button presses and elevator button presses adds requests at a common place.
ElevatorController runs the show by reading the next request to process and instructing the elevator what to do.


How can we extend this to multiple elevators in a sky scraper

In the single elevator scenario, there is an elevator and an elevator controller and a common area where the floor requests and the elevator button request are stored and processed as per the scheduling algorithm.

To extend this to multiple elevators, each elevator will have a corresponding elevator controller. Floor based requests can be served by any elevator where as elevator button requests will be served by the elevator in which the button is pressed.

FloorButton's placeRequest adds a request to the common area which is accessible to all controller. ElevatorButton's placeRequest adds a request to the controller's internal queue as only one elevator is supposed to serve it.

Each elevator controller runs as a separate thread and checks on if it can process a floor request along with processing requests made by its own elevator button presses.

Object oriented design for a digital watch:

Object oriented design for a digital watch:

A simplistic digital displays Hours of the day, minutes of the hour and the seconds of the minute. If you noticed a digital watch the seconds counts refreshes say twice a second and the keeps updating. When the seconds count is 60 seconds hand is reset and the minute count is incremented. Once the minute hand reaches a count 60 the minutes hand is reset and hours hand is incremented. Once the hours count reaches 24 the hours hand is reset to 0.


From the above description, the components of the system are:
1) WatchController
2) SecondsCounter,MinutesCounter,HoursCounter

Below is the class diagram representation:



We have an abstract Type TemporalCounter which defines the method getCounter() returns the current value of the counter which is common for all the counters.

The remaining methods of the class TemporalCounter are abstract and each sub class should define the behavior/declare itself as an abstract class. The reason they are abstract is each subtype has its own different version of increment. For e.g while incrementing seconds counter, once we reach 60 we have to reset the counter and call minutes hand to increment. Same applies for minutes hand increment except that once it reaches 60 it call hours hand increment.

The main controller class supports methods to start and stop the digital watch. Once started, displayTime is executed by the controller. The sub routine for displayTime should be like this

           public void displayTime() {

               while(!stop){
                    secsHand.increment();
                    hoursHand,display()+":"+minsHand.display()+":"+secsHand.display();
               }
            }

Friday, November 9, 2012

Object Oriented design for a cloud based file storage system like SkyDrive

Object Oriented design for a cloud based file storage system like SkyDrive


The typical characteristics/requirements of a cloud storage system:
1) They are essentially file hosting services
2) Allow users to register/sign in
3) Allow registered users to buy more storage
4) Allow users to access/upload/delete the files on the cloud
5) Interact with a Distributed file system to store/delete/retrieve the files on the cloud


From the above description of the system, the main components of the system to be built are:
1) SkyDriveController-> Main controller of the system. Allows user interaction with the system
2) DFSController-> Stores the file in the cloud and also allows access/deletion
3)OperationValidator -> performs validations before allowing user interactions with SkyDrive
4)StorageSpaceAllocator -> allocates extra space for users who want to but space

Lets put down the use cases in visual form:








Above use cases describe the user actions and the corresponding system side actions. Now lets move to the Class diagram to see how the different components inter operate:




The class diagram should help you understand the basic components of a cloud based storage system and should give you enough material to speak up in an interview.  In an interview scenario you can earn some brownie points if you can talk about the Distributed file system implementation. Checkout http://en.wikipedia.org/wiki/Google_File_System#Design to know about how files might be stored on the cloud.

-(
   )antosh