Domain Modelling

Model the reality

Introduction

Consider that you have to model a parking lot. A multi-level parking lot has parkings for Bikes and Car. There are four levels to park the vehicles. On first, second and third floor you can park Cars and fourth floor you can park Bikes.

Modelling

We have to understand the existence of a Parking Lot with given requirement in real life to model it correctly. A Parking Lot has multiple levels. Once the parking lot is built its levels will be constant unless it is enhanced. But in general case we have the number of levels fixed. Hence you can have a parking lot class with multiple parking levels as composition.

A Parking Level will have parkings. A parking has an area or size. To model it simply we can denote size as BIKE and CAR. Hence a parking can either have a size of BIKE or CAR. We can ideally have a single class called Parking with size as a composition having enum values as : BIKE or CAR. But when we think that three floors are reserved for CAR parking and fourth floor for BIKE parking. Hence we will have to represent that as separate Parking class for BIKE and CAR which inherit the protected field size from the Parking abstract class.

An additional property called occupied denoted by a boolean flag is also required for the parking class to represent whether a parking is occupied or not. We could have used the same class to model the Parking Level as well but we should represent the constraints using the model classes. When we design the classes to represent the design constraints then the code becomes more realistic. Hence we will have a abstract class as Parking Level with child classes Bike Parking Level and Car Parking Level.

Instantiating Objects

Now let's create objects for our Parking Lot application. We will need a Parking Lot object which has four Parking Levels out of which three are Car Parking Levels and one is Bike Parking Level. Hence we will have three Car Parking Level Objects and one Bike Parking Level object. A Car Parking Level will have 30 Car Parkings. Hence we will have total 30 X 3 = 90 objects to represent Car Parkings. A Bike parking level has 150 parkings. Hence we will create 150 objects to represent Bike Parkings. To ensure that the number of parkings and parking levels are fixed, we are going to model them as arrays instead of lists since arrays have fixed length. To ensure that number of Car parkings is fixed on each car parking level we are going to provide only name as the constructor argument and in the constructor of the Car Parking Level we will use the fixed value of number of Parkings. Similarly for the Bike Parking Level.

Summary

Object modelling requires clear understanding of requirements and constraints. Once you are clear with this, then using a programming language efficiently to model them and creating a good design is all thats needed. Classes are known as the templates to create multiple objects but also bear in mind that classes should depict the business requirement and constraints effectively. We all know that 20 % of the time of the Software Life goes into Development but 80 % into Enhancing and Maintaining it. Hence ensure that a design is Scalable, Readable and Maintainable.