• 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
  • Tim Cooke
  • paul wheaton
  • Jeanne Boyarsky
  • Ron McLeod
Sheriffs:
  • Paul Clapham
  • Liutauras Vilda
  • Devaka Cooray
Saloon Keepers:
  • Tim Holloway
  • Roland Mueller
Bartenders:

Passed Part 2/3 with 100

 
Greenhorn
Posts: 28
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hello all,

Recieved my part 2 results today after sitting the final exam just over 2 weeks ago. Very quick turnaround and I am very surpised but very happy with the result.

I have been around this great forum for a while now but dont think I ever posted. I found discussion and advice invaluable in completing this certification.

So the website tells me the following:

Sun Certified Enterprise Architect for Java 2 Platform Enterprise Edition Technology Part II (310-061)
Date Taken: 2005-06-15 20:24:22.013
Registration Number: lfcsyd560d
Site: as36
Grade: P
Score: 100
Comment: This report shows the total points that could have been awarded in each section and the actual amount of points you were awarded. This information is provided in order to give you feedback on your relative strengths on a section basis. The maximum number of points you could have received is 100, minimum to pass is 70.
Class Diagram (44 maximum) .......................... 44
Component Diagram (44 maximum) ...................... 44 Sequence/Colloboration Diagrams (12 maximum) ........ 12

A quick summary of my submission:

- Class Diagram - 28 classes. Simple with no data members or methods.
- 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.
- Sequence Diagrams - 4 diagrams for each of the use cases required by the assignment. Prepare Itinerary was pretty damn big.

Assumption document - is big, if I print preview in IE it is around 17 pages. The basic structure and content is:
- Functional Assumptions by use case.
- Deliverable Assumptions and design including BDM, class, component and sequence deliverables.
- General architecture decisions including physical architecture, logical architecture, security, transactions, distributed vs local interfaces, session handling, deployment, design patterns and QOS.
 
Ranch Hand
Posts: 295
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hey Matt,

Excellent score! You really raised the bar, man!
 
Ranch Hand
Posts: 102
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Congrats!!! Excellent score.
 
Ranch Hand
Posts: 446
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Many Congrats !!!

You have definitely raised the bar.

I am seeing a score of 100 after a very long time.

Enjoy your well deserved certification.



 
Greenhorn
Posts: 18
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Congratulations!! If you used an application controller, did you actually show all those related classes in the sequence diagram? Thank you.
 
Ranch Hand
Posts: 223
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Awesome job
So 28 classes in your class diagram. Did you show only technology independent classes, or did you also but technology classes in your diagram as seen in Cade's class diagram? Can you share your approach how you came up with 28 classes since the BDOM has less than 10 business entities. Further, what was your strategy in finding associations and cardinality?

D.
 
Ranch Hand
Posts: 463
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Congratulations. .
Fantastic score.U r the first 100 after almost an year
Dhiren
 
Ranch Hand
Posts: 92
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Congrates
 
Ranch Hand
Posts: 116
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Congrats~
 
Ranch Hand
Posts: 79
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Congrats
 
Matt Rea
Greenhorn
Posts: 28
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
>Awesome job
>So 28 classes in your class diagram. Did you show only technology independent >classes, or did you also but technology classes in your diagram as seen in >Cade's class diagram? Can you share your approach how you came up with 28 >classes since the BDOM has less than 10 business entities. Further, what was >your strategy in finding associations and cardinality?

>D.

My approach to the class diagram was defininately an extension of the BDOM. My class diagram was completely technology independant very much in the style in Cades book except more so in that Cade actually specified some SessionBean components in his class diagram from memory which I did not.

So 28 classes came from extending the ideas of the BDM with other information and requirements from the interview, uses cases etc. For example:
- Equipment can be explored further
- Customer can be explored further(i.e Petstore does this).
- Cades concept of the Processor classes I liked.
- I went a little outside the BDM and actually considered things like the interfaces to other systems and services needed by my system which added a few classes I guess.
- My class diagram wasnt just classes, things like Interfaces are valid.

In terms of association and cardinaty this just came together in reviewing my diagram as I went with the requirements. I really just extended the BDM thinking throught the requirements and how things would work. I found that my choices of design patterns for example later when I was completing my component diagram actually made me revisit my class diagram. For example I chose to use composite entity design pattern and this effected my class diagram associations. I revisited my class diagram continually as I worked on the assignment.

I did change the BDM as well by the way but only the multiplicity between Segment and Flight. Alot of discussion of this but changing this multiplicity for me made the BDM much more flexible but completely backwards compatible with the original diagram.

hope that helps, not really sure how much I can say without saying too much:-)

Matt
 
Ranch Hand
Posts: 101
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Congratulations Matt����

I have a problem with multiplicity between segment and flight in BMD To finish my assigment. I think that it will be: segment *-->1 flight , because segments of different customer could be related to one flight definition.

Is correct to change this cardinality en BDM. Did you changed it???

Waiting for a response ...

Thanks.
 
Jose Jim�nez
Ranch Hand
Posts: 101
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Congratulations Matt����

I have a problem with multiplicity between segment and flight in BMD To finish my assigment. I think that it will be: segment *-->1 flight , because segments of different customer could be related to one flight definition.

Is correct to change this cardinality en BDM???
Did you changed it???

Waiting for a response ...

Thanks.
 
Jose Jim�nez
Ranch Hand
Posts: 101
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Congratulations Matt����

I have a problem with multiplicity between segment and flight in BMD To finish my assigment. I think that it will be: segment *-->1 flight , because segments of different customers could be related to one flight definition.

Is correct to change this cardinality en BDM???
Did you changed it???

Waiting for a response ...

Thanks.
 
Matt Rea
Greenhorn
Posts: 28
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
>>I have a problem with multiplicity between segment and flight in BMD To
>>finish my assigment. I think that it will be: segment *-->1 flight , because
>>segments of different customers could be related to one flight definition.
>>
>>Is correct to change this cardinality en BDM???
>>Did you changed it???

I changed it myself but I have read alot of people pass without changing it at all. The only change I made was the cardinatlity between Segment and Flight. Part of the reason my assumptions document was so long was I fully described all these decisions and documented all assumptions around how I apply the BDM to the problem domain.

I think the opposite to your idea was more valid in my solution, i.e. Flight is the 1..*

This change is really backward compatible with the original BDM in that it can still be a 1->1 relationship depending on the scenario.
 
Ranch Hand
Posts: 211
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Congratulations. 100% would be hard to catch on.

I have a question about your class diagram since you had only 13 classes. Does it include ShoppingCart (or similar) class or you did not show it in your diagram?

Thanks in advance.
PS: This is my first post. Though I have been reading SCEA posts for some weeks now.
 
Ali Hussain
Ranch Hand
Posts: 211
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Sorry for a mistake in my previous post. You had 28 classes My post was meant for another thread. But anyway I can ask the same question here as well. Did you show ShoppingCart-related class in your class diagram?
[ June 20, 2005: Message edited by: Shahid Afridi ]
 
Matt Rea
Greenhorn
Posts: 28
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
>>Sorry for a mistake in my previous post. You had 28 classes My post was
>>meant for another thread. But anyway I can ask the same question here as
>>well. Did you show ShoppingCart-related class in your class diagram?

Yes, I used the shopping cart concept in my class diagram.
 
Jose Jim�nez
Ranch Hand
Posts: 101
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
>>I think the opposite to your idea was more valid in my solution, i.e. >>Flight is the 1..*

>>This change is really backward compatible with the original BDM in that >>it can still be a 1->1 relationship depending on the scenario.

Matt, You say that you used Flight 1--> * Segment, and that it's opposite to my idea ( segment * --> flight )... it isn`t the same ?? Or you are refer to 1 flight have serveral flightleg (segment) ??? THEN... WHERE YOU SAVE THE SEGMENT CHOOSED FOR DE CLIENT ??
 
Greenhorn
Posts: 7
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Congratulations Matt for your perfect score

According to your post your definitions for:
Segment: portion of a trip between two cities under the same flight number or segment of an itinerary (trip between origin and final destination)
Flight (or flight leg): service used to provide the trip

Am I wrong?

Thanks
Marc
 
Matt Rea
Greenhorn
Posts: 28
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi JJ and Marc,

I will answer both your posts in this one. I must admit I had lots of attempts at this area, read lots of posts and throughout the life of my assignment had about 5 different attempts before I was happy with the result.

First Marc,

>>According to your post your definitions for:
>>Segment: portion of a trip between two cities under the same flight number
>>or segment of an itinerary (trip between origin and final destination)
>>Flight (or flight leg): service used to provide the trip

>>Am I wrong?

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.

There a number of solutions to any problem. I think the most important thing in this area is to document your assumptions and describe how your solution meets the business problem.

Hope that answers you question.

JJ Captain,

>>Matt, You say that you used Flight 1--> * Segment, and that it's opposite
>>to my idea ( segment * --> flight )... it isn`t the same ?? Or you are
>>refer to 1 flight have serveral flightleg (segment) ??? THEN... WHERE YOU
>>SAVE THE SEGMENT CHOOSED FOR DE CLIENT ??

Sorry I wasnt clear with my previous answer to your question. My approach was Segment 1 - 1..* Flight. I describe how I thought about segments above in Marcs answer, I think (hopefully) that answers you query. In terms of where I saved the Segment, have a look at the composite entity pattern on the Sun Java blueprints pattern site, my class diagram had aggregation in it due to this design choice.


I along with the large majority of people who do this cert found this area of the business requirements confusing. To define my approach I really used real life experience of some really long flights I took from Australia to Washington DC or Australia to London for example. If you have a look at the complex itineraries for massive trips such as that you get some great scenario's to validate your model. In documenting my assumptions and application of my solution to the business problem I did exactly this.

Rgds,

Matt
 
Matt Rea
Greenhorn
Posts: 28
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
>>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.

A quick clarification of the above as I dont think I was clear enough. What I trying to say is a trip A->C->B can be defined in a number of ways depending on how you define segment, flight and the cardinality between them. Could be multiple segments with single flights.... or it could be a single segment with multiple flights.... Both can be correct depending on how your define things and your assumptions.

Hope that is clearer.

Matt
 
Jose Jim�nez
Ranch Hand
Posts: 101
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Matt...

For you said it, you used segment and flight as master tables, no?
Then one reserve for a client, could insert several registers in itenerary table (one for each segment choosed) ??

Thank Matt ����
 
Matt Rea
Greenhorn
Posts: 28
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
>>For you said it, you used segment and flight as master tables, no?
>>Then one reserve for a client, could insert several registers in itenerary
>>table (one for each segment choosed) ??

Hi JJ,

I apologies but I am not sure what you mean by the above. Looks like you are going into alot more detail that maybe is more relevant to a detailed design rather than a solution archtitecture. The specifics of the database schema and implementation details of my persistence mechanism were not something I included.

Matt
 
Marc Pourier
Greenhorn
Posts: 7
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Matt

In an association as below:
Customer 1-->0..* Itinerary 1-->1..* Segment 1--> 1..* Flight.
something is missed between Customer and Itinerary !! One (or more) Flight associated to only one Customer ??

Thanks
Marc
 
Matt Rea
Greenhorn
Posts: 28
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
>>In an association as below:
>>Customer 1-->0..* Itinerary 1-->1..* Segment 1--> 1..* Flight.
>>something is missed between Customer and Itinerary !!

Hi Marc,

Your association is how I approached in my BDM. When I extended the BDM there was definately some extra classes between customer and itinerary. Things similar to the concept of a shopping cart like class and the concept of Processor or Manager classes as in Cades book I found very relevant.

>> One (or more) Flight associated to only one Customer ?

Not quite sure what you mean here.... But at a high level, in terms of one or more flights associated with only one customer remember that our solution is a flight booking system. At the end of the day a customer is booking just seats on flights between locations. Once booked the customer has that seat and remaining seats are available for other customers to book. So when you book a itinerary for a customer, the customer has a 1+ segments, each which may have 1+ flights with associated equipment and seats. Other customer may have instances of the same segment, flight and equipment objects but different seats obviously.

Does that answer your question? I may very well have just rambled alot and never got close to what you were asking

Rgds

Matt
 
Marc Pourier
Greenhorn
Posts: 7
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Matt

Thanks, it's ok, my question was just about the different multiplicities as defined in the BDM.
Customer 1--> 1 Itinerary is wrong if you define Itinerary as a trip (in this case you should have at least one class between Customer and Itinerary), but it's correct if Itinerary means "booked itinerary" (reservation).
Thanks again Matt

Regards
Marc
 
Marc Pourier
Greenhorn
Posts: 7
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Sorry ! a typo...

Customer 1--> 0..* Itinerary

Regards
Marc
 
Ranch Hand
Posts: 1327
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
congratulations, i suppose now u can put the score on ur resume/cv
 
Mark Cave
Ranch Hand
Posts: 92
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Matt,

Could you please clarify my confusion in the way you defined flight and segment?

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.

 
Ranch Hand
Posts: 208
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

- 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



Matt,
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...
 
David Follow
Ranch Hand
Posts: 223
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Matt,

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).

D.
 
Ranch Hand
Posts: 498
Eclipse IDE Firefox Browser Fedora
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Congrats Matt, great job!



Regards,
 
Ranch Hand
Posts: 63
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Congrats Matt

You deserved it .
 
Matt Rea
Greenhorn
Posts: 28
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator


Matt,
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...



Yes, I including a Cart class in my class diagram. I also included the Cart in the component diagram where it was relevant. My class diagram was completely technology independant. There were a number of classes that appeared in my component diagrams such as session facades for one example.

I also did have duplicate components, ServiceLocator is a perfect example. One of my component diagrams was really busy/complex so I left some components out. In these cases I used notes to reference that they would be used, why they were left out and where an example of how they were used in another component diagram.

Matt
[ June 22, 2005: Message edited by: Matt Rea ]
 
Matt Rea
Greenhorn
Posts: 28
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator


Hi Matt,

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).

D.



Hi David,

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

Rgds,

Matt
 
Mark Cave
Ranch Hand
Posts: 92
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Matt,

Hi David,

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

Rgds,

Matt


Thanks, sure that helped a lot.

I have one ore question if you can help me:

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.


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.
 
Matt Rea
Greenhorn
Posts: 28
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator


Could you please clarify my confusion in the way you defined flight and segment?



Mark,

I so do not know how much detail I am allowed to give before I cross that line and give away too much... I am hoping a admin will edit if I do that by ignorance.

I have seen discussion in the forum about data members at Segment, flight etc. I didnt show them in my class diagram but I did make some assumptions about my meanings for segment and flight and "key" data elements.

Segment was a trip from city x to city z.

Flight is a flight number but for me could also have city A to city B. As I described in my previous post in response to David I can have multiple flights to a segment, akin to what other people have defined as legs.

So Segment X->Z as on the itinerary may in fact be in practice X->Y->Z and as such include two flights as per my model:
1)Flight123: X->Y
2)Flight123: Y->Z (Same Flight number in this case BUT could as easily be different.

In my previous post I highlighted a scenario where you the above flights may keep the same flight number but have different equipment associated. This happened to me in real life. It could have just as easily been a new flight number which in this case you could define it as 2 segments and keep the original BDM and it would work... i think

Hope that answers your question, doesnt cross the line and is useful,

Rgds,

Matt
 
Matt Rea
Greenhorn
Posts: 28
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator


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.



Mark,

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
-> Flight123->Equipment456

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).

Rgds,

Matt
 
Mark Cave
Ranch Hand
Posts: 92
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Matt,

Mark,

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
-> Flight123->Equipment456

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).



Thanks for you help. So in your design it is possible for a flight to have a list of eqiopments. Hence, you changed the multiplicity between Flight and Equipment as well. Am I worng?
 
A day job? In an office? My worst nightmare! Comfort me tiny ad!
We need your help - Coderanch server fundraiser
https://coderanch.com/wiki/782867/Coderanch-server-fundraiser
reply
    Bookmark Topic Watch Topic
  • New Topic