Identifying Domain Classes from the Problem Statements
Click submit to view solution
The latest cab services agency in the city has approached you to develop a Cab Management System for them. Following is the information they have given to implement the system.
Mr. Bose is the boss of this agency. Cabs are solely owned by the agency. They hire drivers to drive the cabs. Most of the cabs are without AC. However, a few comes with AC.
The agency provides service from 8 AM to 8 PM. Presently the service is limited only within Kolkata. Whenever any passenger books a cab, an available cab is allocated for him. A booking receipt is given to the passenger. He is then dropped to his home, office, or wherever he wants to go. In case the place is in too interior, the passenger is dropped at the nearest landmark.
Payments are made to the drivers by cheque drawn at the local branch of At Your Risk Bank. All kind of finances required for the business are dealt with this bank.
Recently Mr. Roy, neighbour of Mr. Bose, has given a proposal to book one of the cab in the morning everyday to drop his son to school, and drop him back to home later. Few other persons in the locality have also found the plan a good one. Hence, Mr. Bose is planning to introduce this "Drop to school" plan also very soon.
Limitations: The workspace provided is constrained to solve the current problem only. This is not a general user interface to solve any problem. Moreover, the classes generated at the end are some rudimentary classes and not necessarily the only classes possible. UML works in an iterative approach -- propose and refine. In fact, one may model the problem from a different perspective. The objective here is to provide an idea on how one should begin identifying potential candidate classes.
From the given problem statement we can identify the following nouns and noun phrases:
Noun and Noun Phrases | |||||
---|---|---|---|---|---|
|
|
|
|
|
|
Let us put the above into different categories.
People | Places | Things | Organizations | Concepts | Events |
---|---|---|---|---|---|
|
|
|
|
|
|
The nouns and noun phrases in the problem statement gives us a list of 31 potential classes. However, all of them may not be relevant. For example, 'Moning' is not something related to the Cab Management System. And so is 'Everyday'. In a similar way, 'Service', 'Plan', 'Agency', 'AC', 'Locality', and 'Business' doesn't seem to be potential classes in this context. So, we may avoid to assign any attributes for those entries.
We need to assign some attributes for rest of the potential classes. For example, 'Mr Roy' may assigned attributes 'Adress', 'Height', 'Name', and 'Weight'. In addission to these, 'Customer id', may be consider as an attribute for 'Mr Roy', as, Mr Roy may be treated as a potential Customer for our Cab Management System. Similarly, we can assign attribute 'Employee id' with 'Adress', 'Height', 'Name', and 'Weight' for the potential class 'Drivers'.
These are the probable classes with their associated properties
Person | Employee | Customer | Place | Cab | Booking | Bank |
---|---|---|---|---|---|---|
|
|
|
|
|
|
|
According to the properties assigned to 'Mr Roy' and 'Drivers', Mr Roy will be an object of 'Customer' class and 'Drivers' will be an object of 'Emloyee' class.
Although not explicitly mentioned in the problem statement, based on knowledge in related area one may point out few other potential classes with their following properties:
Transaction | Payment |
---|---|
|
|
For the given problem related to Cab Management System, one may conclude the final list of classes as :