Passed Part II and III
Francis Sommers
Greenhorn
Posts: 13
posted 10 years ago
I received my grade today after 4 weeks + 1 day.
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) .......................... 36
Component Diagram (44 maximum) ...................... 44 Sequence/Colloboration Diagrams (12 maximum) ........ 12
Obviously my class diagram was where I lost 8 points. I used the original BDM and extended it but also included some of the implementation classes.
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) .......................... 36
Component Diagram (44 maximum) ...................... 44 Sequence/Colloboration Diagrams (12 maximum) ........ 12
Obviously my class diagram was where I lost 8 points. I used the original BDM and extended it but also included some of the implementation classes.
rajesh ganapathy
Greenhorn
Posts: 4
Francis Sommers
Greenhorn
Posts: 13
posted 10 years ago
I didn't specifically address protocols on any of my diagrams but I did cover it in my design / architecture overview and assumptions document. I justified the choice of interface to the Frequent Flyer system and to the Transmaster Payment system in my architecture doc. I did cover security in my component diagrams. I covered how the authentication would work as well as I had componments to show the physical security store I used. I also had specific sequence charts for the authentication / authorization and covered security in detail in my architecture overview. I think I am not allowed to provide any more details than that based on the Sun rules.
Andreas Enbohm
Greenhorn
Posts: 11
Muhammad Asif
Ranch Hand
Posts: 202
Ayman Atiyeh
Greenhorn
Posts: 2
posted 10 years ago
I have some questions regarding flight pricing,
As mentioned on the Prepare Itinerary use-case (System responds with the selected flight priced and alternative flights if less than selected). This paragraph means that we must price the selected and alternative flights using the Price Itinerary use-case.
But according to the Prepare Itinerary use-case, we must price the itinerary again after selecting the seats. Why should we if the itinerary was already priced.
Is selecting flights seats will effect the flights price (already calculated). I assumed the customer already chooses the cabin class (first class or coach).
The Price Itinerary use-case has the following pre-conditions: customer logged in, customer has profile, and customer has a prepared itinerary. BUT: When we price the selected/alternative flights the user is not logged in yet and the prepare itinerary is not completed (seats not selected yet).
This contradiction on the provided use cases make it impossible to provide a design without violating some of the requirements.
DON�T YOU THINK
Another question,
Since the flight may contain more than on cabin class (first class and coach) and the seat price depends on the selected cabin, a new class Cabin must be added between the equipment class an Seats. The question is where do I have to define the price of the flight seat.
I treated equipment, cabin, and seat as a static data. An new equipment record will be added only when FBN buys a new airplane. So I have to solutions: -
First: save cabin seat price on the flight class, two attribute (firstClassPrice and coachPrice).
Second: Adding a new Class FlightCabin which contains the cabin seat price. The association will be Flight 1 --> 1..* FlightCabin
As mentioned on the Prepare Itinerary use-case (System responds with the selected flight priced and alternative flights if less than selected). This paragraph means that we must price the selected and alternative flights using the Price Itinerary use-case.
But according to the Prepare Itinerary use-case, we must price the itinerary again after selecting the seats. Why should we if the itinerary was already priced.
Is selecting flights seats will effect the flights price (already calculated). I assumed the customer already chooses the cabin class (first class or coach).
The Price Itinerary use-case has the following pre-conditions: customer logged in, customer has profile, and customer has a prepared itinerary. BUT: When we price the selected/alternative flights the user is not logged in yet and the prepare itinerary is not completed (seats not selected yet).
This contradiction on the provided use cases make it impossible to provide a design without violating some of the requirements.
DON�T YOU THINK
Another question,
Since the flight may contain more than on cabin class (first class and coach) and the seat price depends on the selected cabin, a new class Cabin must be added between the equipment class an Seats. The question is where do I have to define the price of the flight seat.
I treated equipment, cabin, and seat as a static data. An new equipment record will be added only when FBN buys a new airplane. So I have to solutions: -
First: save cabin seat price on the flight class, two attribute (firstClassPrice and coachPrice).
Second: Adding a new Class FlightCabin which contains the cabin seat price. The association will be Flight 1 --> 1..* FlightCabin
Francis Sommers
Greenhorn
Posts: 13
posted 10 years ago
In the first step the system returns prices for a whole number of flights. Once the user selects the specific flights they want the requirements state "The system prices the itinerary" I assumed (and documented the assumption) that this means the system calculates the total cost of the trip based on the segments the user selected. That was my assumption but the point is you should make assumptions where there are contradictions in the requirements and document those assumptions.
On the other issue there is no mention of different classes of tickets. The requirements indicate there is "one flat price per destination" so don't make your solution any more complicated than it needs to be.
On the other issue there is no mention of different classes of tickets. The requirements indicate there is "one flat price per destination" so don't make your solution any more complicated than it needs to be.
