aspose file tools*
The moose likes Architect Certification (SCEA/OCMJEA) and the fly likes BDM - cardinality of Flight - Segment relationship Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Certification » Architect Certification (SCEA/OCMJEA)
Bookmark "BDM - cardinality of Flight - Segment relationship" Watch "BDM - cardinality of Flight - Segment relationship" New topic
Author

BDM - cardinality of Flight - Segment relationship

Andrew Zilahi
Ranch Hand

Joined: Oct 16, 2006
Posts: 47
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


--------------------------<br />SCJP,SCJD,IBM XML, SCEA 1
sai maddikay
Greenhorn

Joined: Jul 03, 2006
Posts: 14
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

Joined: Oct 16, 2006
Posts: 47
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
Dan Drillich
Ranch Hand

Joined: Jul 09, 2001
Posts: 1164
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


William Butler Yeats: All life is a preparation for something that probably will never happen. Unless you make it happen.
Andy Malakov
Greenhorn

Joined: Aug 30, 2006
Posts: 26
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

Joined: Oct 16, 2006
Posts: 47
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 ]
Lars Behnke
Ranch Hand

Joined: May 09, 2006
Posts: 76
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

Joined: Oct 16, 2006
Posts: 47
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

Joined: May 09, 2006
Posts: 76

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

Joined: Oct 16, 2006
Posts: 47
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

Joined: May 09, 2006
Posts: 76

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

Joined: Oct 16, 2006
Posts: 47
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

Joined: May 09, 2006
Posts: 76
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

Joined: Oct 16, 2006
Posts: 47
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
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: BDM - cardinality of Flight - Segment relationship
 
Similar Threads
A question about part2
Cade's BDM & Class Diagram
Part 2 - Flight x Segment
Part 2 - Doubt about the meaning of "Segment"
Flight and segment