• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Liutauras Vilda
  • Campbell Ritchie
  • Tim Cooke
  • Bear Bibeault
  • Devaka Cooray
Sheriffs:
  • Jeanne Boyarsky
  • Knute Snortum
  • Junilu Lacar
Saloon Keepers:
  • Tim Moores
  • Ganesh Patekar
  • Stephan van Hulst
  • Pete Letkeman
  • Carey Brown
Bartenders:
  • Tim Holloway
  • Ron McLeod
  • Vijitha Kumara

FBN Object Design  RSS feed

 
Ranch Hand
Posts: 218
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hello,

I am designing the object model, and have some confusion on: itinerary -> segments -> flights -> equipment -> seats.

My thinking is as follows: There must be a flight table in the database which gets updated many times during an hour to delete old flights, etc. There must also be an equipment table which contains static data pertaining to each airplane. Should the object model contain objects to contain this data? I know that we do not have to list all of the data fields in the model, but feel as architects we should have an idea about the sort of data we want in the model. For example, I am thinking that the equipment class in the model would only have a primary key for the flight and a primary key for the plane; the flight primary key would point to a table which gets updated quite frequently and the equipment primary key would point to a table with detailed static data about the plane (not the seats). This data separation would help the efficiency of the booking system. So I am saying that the booking data would be in separate tables from the table containing all flights and the plane's static data.

I am wondering if we should model for data which must exist, but is not populated by any of the four use cases.

I believe these details should be reflected in the class design. Is this correct?

Thanks for any help.

Saha
 
Ranch Hand
Posts: 39
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
You are right that Equipment in the domain model is supposed to represent an airplane (which is not mentioned in the business domain model drawn by the business analyst).

Now you can either assume in the domain model that the persistence table structure is deferred to the DAO layer OR add another class called Airplane AND/OR show a data-model containing all the tables and their relationships (TBL_ITINERARY, TBL_EQUIPMENT, TBL_PLANE etc)

I prefer the first approach.

Basically, remember that the table associations in the data model don't necessarily have to be the same as the class/object associations in the domain model! That is precisely the advantage of having a data-access layer!




Originally posted by Saha Kumar:
Hello,

I am designing the object model, and have some confusion on: itinerary -> segments -> flights -> equipment -> seats.

My thinking is as follows: There must be a flight table in the database which gets updated many times during an hour to delete old flights, etc. There must also be an equipment table which contains static data pertaining to each airplane. Should the object model contain objects to contain this data? I know that we do not have to list all of the data fields in the model, but feel as architects we should have an idea about the sort of data we want in the model. For example, I am thinking that the equipment class in the model would only have a primary key for the flight and a primary key for the plane; the flight primary key would point to a table which gets updated quite frequently and the equipment primary key would point to a table with detailed static data about the plane (not the seats). This data separation would help the efficiency of the booking system. So I am saying that the booking data would be in separate tables from the table containing all flights and the plane's static data.

I am wondering if we should model for data which must exist, but is not populated by any of the four use cases.

I believe these details should be reflected in the class design. Is this correct?

Thanks for any help.

Saha


[ February 27, 2006: Message edited by: Akshay Shrivastava ]
 
Saha Kumar
Ranch Hand
Posts: 218
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks for your reply...I was thinking the same.
 
Don't get me started about those stupid light bulbs.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!