Segment I define as trip between to cities. Because I changed my BDM this can be made up of one or more flights (i.e individual flight numbers). A Itinerary can be made up of a number of segments which in turn can be made of a number of flights. In real life things can get complex, our old favorite scenario of a trip between city A and city B may not be a direct flight. ie. May go A->C->B and there is nothing stopping some passengers getting off or joining the flight in City C. There is nothing to say you cannot also treat A->C and C->B as seperate segments, in the BDM and my class diagram.
- Component Diagrams - Split into 3 seperate diagrams. Based thinking along the lines of Cades book. Lots of notes to describe patterns used and stereotypes to describe J2EE componenets
In one of your post, you mentioned showing shopping cart concept in your class diagram. Do you also show the ShoppingCart concept in your component diagram? Cade doesn't show it in any of his three component diagrams, yet ShoppigCart is represented as a statefull session bean which is a component.
What do you think three are duplicate components in each component diagram? e.g. ServiceLocator, BusinessDelegate, InterceptingFilter, etc...
I am also confused about your definition of segment.
For me a segment ist defined als follows:
A itinirary of A -> B -> C (one way only)
is made up of the 2 segments A->B and B->C
Further the segment A->B has a 1:1 relationship with flight.
Because in my understanding flight-equipment-seat is read-only data
whereas the segment belongs to a customer through the customer's itinarary.
However, segment and flight would hold similar information.
Does this sound ok or am I missing something?
I am just trying to make sense of the given BDOM since I would prefer not to change the BDOM (which would be changing the requirements).
I think there are any number of approaches and solutions to the Itinerary/Segment/Flight etc BDM issue. You just need to be clear in your own mind on how you apply it to the problem domain and constrain your solution with relevant assumptions. My way is only one approach and given the amount of discussion on the list over the last few years I have seen a number of approaches that are all valid and got very good marks.
I changed the BDM to fit with my solution making Segment and Flight 1 - 1..* Given I have tried to explain this a few times, rambled alot and have probably confused everyone more I will try to highlight a real life example I found very relevant and enlightenting to validating my model.
I took a flight from Melbourne, Australia to Washington DC, USA and lets just stick to one way. I did this in real life, took 30 hours which was hell but that is not the main point here
Itinerary had 2 Segments.
- Segment 1: Melbourne to San Fransisco with flight number 123.
- Segment 2: San Fran to Washington DC with flight number 456.
Segment 1 was where I didnt like the original BDM. Basically Melbourne to San Fran was really Melbourne->Sydney->San Fran. Some passengers only went form Melb->Sydney as overflow on domestic flights I guess and some passengers joined in Sydney to go on to San Fran. We actually changed aircraft type in Sydney but kept the same flight number. I described this scenareo in detail in my assumptions/design document to defend my decision to change the BDM ever so slightly and the model was applied.
Segment 2 was a nice and simple so no issue there with the old BDM.
In thinking about scenario 1 I just didnt like the way the original BDM handled it. That doesnt mean mine is the only solution. Leaving the BDM as is and coming up with alternative solutions could be 100% correct. I am pretty sure my good mark came down to fully documenting my assumptions and design rather than this approach being the only valid solution.
David, hope that help... or I have just confused everyone more
Basically Melbourne to San Fran was really Melbourne->Sydney->San Fran. Some passengers only went form Melb->Sydney as overflow on domestic flights I guess and some passengers joined in Sydney to go on to San Fran. We actually changed aircraft type in Sydney but kept the same flight number.
Could you please clarify my confusion in the way you defined flight and segment?
Why did you change the relationship from 1-1 into Segment 1 - * Flight. In your scenario, you mentioned that the flight number didn't change. How did that support you? In this case you have two flights with the same number but each is associated with a different aircraft.
I changed the relationship exactly between Segment and Flight because of the change of equipment but the same flight number. I made perfect sense to me at the time and I am very sure there are other ways to represent it.
Segment1 -> Flight123->Equipment123
I just thought about how my itinerary for that trip was structured and with the printed Itinerary that I was given the stop over in Sydney and the change of plane was never mentioned at all. It was a internal representation that was still very relevant for this application as it impacts seat booking and also supports the concept of other customers booking Segments that may be parts of other Segments (i.e. Joining the flight in Sydney to continue onto San Fran, using my example from previous posts).
Screaming fools! It's nothing more than a tiny ad:
Building a Better World in your Backyard by Paul Wheaton and Shawn Klassen-Koophttps://coderanch.com/wiki/718759/books/Building-World-Backyard-Paul-Wheaton