aspose file tools*
The moose likes Architect Certification (SCEA/OCMJEA) and the fly likes Passed Part 2/3 with 100 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 "Passed Part 2/3 with 100" Watch "Passed Part 2/3 with 100" New topic
Author

Passed Part 2/3 with 100

Matt Rea
Greenhorn

Joined: Apr 22, 2003
Posts: 28
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.
Steven Wong
Ranch Hand

Joined: Mar 07, 2002
Posts: 295
Hey Matt,

Excellent score! You really raised the bar, man!


best regards,<br />Steven<br />SCJP, SCEA
subu ananthram
Ranch Hand

Joined: May 16, 2004
Posts: 102
Congrats!!! Excellent score.
Deepak Pant
Ranch Hand

Joined: Feb 13, 2004
Posts: 443
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.



Kate Young
Greenhorn

Joined: Jun 14, 2005
Posts: 18
Congratulations!! If you used an application controller, did you actually show all those related classes in the sequence diagram? Thank you.
David Follow
Ranch Hand

Joined: Oct 16, 2001
Posts: 223
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.


SCJP, SCEA
Dhiren Joshi
Ranch Hand

Joined: Dec 09, 2003
Posts: 463
Congratulations. .
Fantastic score.U r the first 100 after almost an year
Dhiren
Mark Cave
Ranch Hand

Joined: May 22, 2005
Posts: 92
Congrates
David Taun
Ranch Hand

Joined: Oct 28, 2001
Posts: 116
Congrats~
Jeremy Hsu
Ranch Hand

Joined: Mar 28, 2005
Posts: 79
Congrats
Matt Rea
Greenhorn

Joined: Apr 22, 2003
Posts: 28
>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
Jose Jim�nez
Ranch Hand

Joined: Jun 15, 2005
Posts: 101
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.


SCEA<br />SCWCD<br />SCJP
Jose Jim�nez
Ranch Hand

Joined: Jun 15, 2005
Posts: 101
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

Joined: Jun 15, 2005
Posts: 101
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

Joined: Apr 22, 2003
Posts: 28
>>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.
Ali Hussain
Ranch Hand

Joined: Jun 19, 2005
Posts: 211
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.


- SCEA, SCJD, SCBCD, SCWCD, SCMAD, SCJP, ICAD (WebSphere), Lotus Principal CLP, Lotus CLP, Lotus CLS
Ali Hussain
Ranch Hand

Joined: Jun 19, 2005
Posts: 211
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

Joined: Apr 22, 2003
Posts: 28
>>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

Joined: Jun 15, 2005
Posts: 101
>>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 ??
Marc Pourier
Greenhorn

Joined: Jun 19, 2005
Posts: 7
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

Joined: Apr 22, 2003
Posts: 28
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

Joined: Apr 22, 2003
Posts: 28
>>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

Joined: Jun 15, 2005
Posts: 101
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

Joined: Apr 22, 2003
Posts: 28
>>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

Joined: Jun 19, 2005
Posts: 7
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

Joined: Apr 22, 2003
Posts: 28
>>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

Joined: Jun 19, 2005
Posts: 7
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

Joined: Jun 19, 2005
Posts: 7
Sorry ! a typo...

Customer 1--> 0..* Itinerary

Regards
Marc
Billy Tsai
Ranch Hand

Joined: May 23, 2003
Posts: 1304
congratulations, i suppose now u can put the score on ur resume/cv


BEA 8.1 Certified Administrator, IBM Certified Solution Developer For XML 1.1 and Related Technologies, SCJP, SCWCD, SCBCD, SCDJWS, SCJD, SCEA,
Oracle Certified Master Java EE 5 Enterprise Architect
Mark Cave
Ranch Hand

Joined: May 22, 2005
Posts: 92
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.
vu lee
Ranch Hand

Joined: Apr 19, 2005
Posts: 189
- 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

Joined: Oct 16, 2001
Posts: 223
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.
Marcelo Sousa Ancelmo
Ranch Hand

Joined: Jan 17, 2002
Posts: 497

Congrats Matt, great job!



Regards,


Marcelo Sousa Ancelmo - Brazil
Paulo Asterio Nunes
Ranch Hand

Joined: Jul 06, 2004
Posts: 63
Congrats Matt

You deserved it .


Regards,<br /> <br />Paulo Nunes (Brazil)<br />MCP OCP IBM285 SCJP 1.4 SCWCD 1.4 SCBCD 1.3 SCEA (I)
Matt Rea
Greenhorn

Joined: Apr 22, 2003
Posts: 28

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

Joined: Apr 22, 2003
Posts: 28

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

Joined: May 22, 2005
Posts: 92
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

Joined: Apr 22, 2003
Posts: 28

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

Joined: Apr 22, 2003
Posts: 28

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

Joined: May 22, 2005
Posts: 92
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?
 
wood burning stoves
 
subject: Passed Part 2/3 with 100