Class Diagrams and OCL Airline Example 1. Specify the following - - PDF document

Class Diagrams and OCL Airline Example

• 1. Specify the following invariants using the OCL:
• 1. For a given flight, the originating airport must not be

the same as the destination airport. context Flight inv: origin <> destination

• 2. If a flight plane has more than 300 seats then each of

its flight sections must have at least 20 seats and at most 100 seats. context FlightPlane

inv: numberOfSeats > 300 implies self.flightSection - > forAll(fs: fs.flightSeat -> size() > 19 and fs.flightSeat -> size() < 101)

• 3. The numberOfSeats derived attribute must be equal to

number of seats linked to a filght plane context FlightPlane::numberOfSeats:integer derive: self.flightSeat -> size()

• 2. Define new query operations, using the OCL, that

provide the following information from the class diagram:

• 1. The set of bookings for an airline on a specified date.
• 2. The flight sections on a flight that have seats that have

not been booked.

• 3. The flight sections on a flight that have all seats

booked.

• 3. Modify the above class diagram to reflect the following

requirements (include additional OCL constraints if needed):

• 1. A flight attendant can be assigned to at most one flight
• section. Each section has one attendant that is the

supervisor for the section. A supervisor must have at least 10 years of service. If there are greater than 200 seats in a section then at least 4 attendants must be

assigned to the section.

• 2. A flight can be associated with more than one airline

(code sharing). The flight is still operated by one airline, but it can be associated with more than one

• airline. An airline cannot co-share a flight with itself.
• 3. A flight can have many “legs”, that is, it can have

more than one destination (each destination is different). Each leg has an origin and a destination, where the origin of a leg other than the first leg is the destination of the previous leg.

• 4. One may be tempted to model FlightSeat as an

association class for the bookedFor association. What is the problem that can occur if this is done? (HINT: make sure you understand the implications of the semantics of association classes. The problem has nothing to do with implementation of association classes in programming languages so please do not state that as a reason)