• 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 Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

BDM - cardinality of Flight - Segment relationship

 
Ranch Hand
Posts: 47
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I am trying to interpret the 1-to-1 relationship between segment and flight, but in my understanding, a "flight" is really characterized by a flight # and the scheduled date. If this is indeed the case, relationship should be:

Segment * ----- 1 Flight

Any feedback greatly appreciated!

Thanks
 
Greenhorn
Posts: 14
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
here is my understanding...

An Itinerary must have at least 1 segment (Min. one-way i.e. a direct flight (can have more than one segment if not a direct flight))

Itinerary: includes everything from start to end.

According to the BDM a segment has only one flight

for example: a itinerary(one-way) from detroit to san jose (with a stop at minneapolis)

so here there are two segments:
detroit - minneapolis
minneapolis - san jose

it dosent matter if the flight no. remains the same or changes, but for sure each segment is associated with only one flight according to the BDM.

any thoughts ..suggestions.
sai

[ October 21, 2006: Message edited by: sai ]
[ October 21, 2006: Message edited by: sai ]
 
Andrew Zilahi
Ranch Hand
Posts: 47
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I guess my point is that, since Flight is "read only" object, i.e. most likely only contains flight number, etc., why have an instance of it for every segment.

Does it make sense? In other words, Flight has no specific data to a particular Itimerary, Segment, Seat, etc.

thanks,
A
 
Ranch Hand
Posts: 1183
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Andrew, you said that the relationship should be:

Segment * ----- 1 Flight



You are absolutely right. There is no doubt that this is the correct relationship. However, what type of relationship? It is the relationship at the DB level. At the DB level, you 'instantiate' the segment and flight tables exactly once. One table for each entity. It means, obviously, that the DB schema is the object schema - There is no separation between these two.

The BDM, however, is different. Here the relations are among multiple objects and it's up to you to decide about the 'visibility' of objects. Not always all the objects need to see all the other objects. And that's exactly what sai said. If the BDM is from the itinerary perspective then the visibility is such and such.

Regards,
Dan
 
Greenhorn
Posts: 26
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
IMHO if Flight is defined as a flight of specific aircraft on a specific date it will carry many passengers and hence will be referenced by multiple Itineraries(Segments).
[ October 26, 2006: Message edited by: Andy Malakov ]
 
Andrew Zilahi
Ranch Hand
Posts: 47
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I agree with Andy. Let's take one step back and define these entities:

Please note that none of the entities below carries any customer specific data:

- flight = a service performed by airline from airport A to airport B on a particular date at a particular time. Nothing customer specific. Multiple itineraries can be associated with the same flight (hence should associate with multiple segments)

- equipment = an instance of a particular aircracft model. can be used for multiple flights, although at any point in time can be associated with only one flight (hence 1-to-1 relationship with flight??)

- seats = (btw, plural is incorrect in BDM). An inventory of all seats for particular aircraft; *not the customer's reserved seats*. Reserved seats for specific customer should be stored somewhere else. It is also not the list of available (unreserved seats).

Let's clarify these definitions. Do you all agree??

thanks,
Andrew
[ October 26, 2006: Message edited by: Andrew Zilahi ]
 
Ranch Hand
Posts: 76
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Andrew,

I agree with Dan concerning the visibility of the flight class.
IMO business objects should not be shared among components, that is why transfer objects exist. In my understanding itinerary (which is specific for a customer) and flight belong to different components (e.g. CustomerManagement and Schedule). Hence, it is sufficient for the itinerary class to hold the primary key (e.g. flight number, flight ID).

Concerning the terminology I have another understand of the word 'equipment'. Equipment and seat are equivalent IMO. I am not a native english speaker (as you may have noticed) so I could be wrong.
 
Andrew Zilahi
Ranch Hand
Posts: 47
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Lars,
If I understand what you're saying, instead of having a Flight object that contains all flight details (depart/arrival airport, time, etc) just have a lightweight object wrapping the flight ID or something?
Both you and Dan are suggesting some sort of containment as opposed to aggregation.
I think it all boils down to how you want to use those classes, so either approach could work.
Equipment = aircraft (there is a consensus on this on this forum).

Please confirm my understanding.

Regards,
Andrew
 
Lars Behnke
Ranch Hand
Posts: 76
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator


instead of having a Flight object that contains all flight details (depart/arrival airport, time, etc) just have a lightweight object wrapping the flight ID or something?



The lightweight object would be a Long-Object .
If you want to return a complete segment including flight data etc to the client you could assemble the corresponding transfer objects (SegmentTO, FlightTO).

Of course, there may be a reason to opt for a sort of wrapper object and/or accept some redundancy in your model - but I don't see one.

Please note that this is MHO and I am not certified yet.
 
Andrew Zilahi
Ranch Hand
Posts: 47
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
TO is technology specific and hence should not be part of the BDM. Technology should not be the driver when deciding on the class diagram.

Besides Itinerary, Segment, Flight, etc. might only exist on the server side!
I would rather probably go with complete object, and alter the BDM cardinality (who says you cannot?).

Rgds,
Andrew
 
Lars Behnke
Ranch Hand
Posts: 76
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator


TO is technology specific and hence should not be part of the BDM. Technology should not be the driver when deciding on the class diagram.



I agree with you that the BDM is not technology-specific and it is not the place to put DTOs. But we are talking about the class diagram after all, right? I suppose you got me wrong here.


Besides Itinerary, Segment, Flight, etc. might only exist on the server side!



Again, I agree with you that the corresponding classes belong the business layer. It is up to you whether to use these business classes or DTOs to transport data across layers and components. Whatever solution you choose, it should be fine as long as you can justify your decision.
 
Andrew Zilahi
Ranch Hand
Posts: 47
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I bet one of the scoring criteria for class diagram is maintainability.
My thought is that, in order to be able to change functionality, the business object class diagram should be designed properly (i.e. no compromises). You can than later "wrap" these objects in EJBObject, VO, etc. etc.
You get my point?

thanks,
Andrew
 
Lars Behnke
Ranch Hand
Posts: 76
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Andrew,

I feel we are getting a little bit off topic now, but I think the key questions we must ask ourselfs are:

1. In which level detail do we want to model the class diagram?
2. Is the class diagram supposed to be technology independent?

After reading some other posts I got the impression that people who took an simple (Cade-like) approach have scored higher. Your point. However, this is an J2EE certification after all and I cannot believe that Sun does not expect the candidates to apply J2EE design patterns.

Regards,
Lars
 
Andrew Zilahi
Ranch Hand
Posts: 47
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Here is what I filtered from top performers:

- class diagram has no J2EE specifics in it. Only business model specific classes that extend existing BDM and have additional classes to cover use cases
- one sequence dialgram by use case. your choice whether you want to put alternative flow on same diagram. Sequence diagram may not use concrete classes from class diagram, and hence no specific method calls
- component diagram is for you to include all J2EE patters

I suggest that you spend some time reading posts on the forum and let me (us) know if you disagree.

Thanks,
Andrew
 
reply
    Bookmark Topic Watch Topic
  • New Topic