please just draw UML class diagram and all the object diagram. This is java assignment. i am got little confusing about the diagram. Please don't code.

Project 1: Aloha Airlines Flights, Part 1 1 Task Aloha Airlines wants a proof of concept for a flight booking system, implement supplier code for them. Flights: each flight has a flight number (alphanumeric), an origin and a destination (a three-letter, upper- case airport codes), and a date. Once the flight is set up, none of this information can be changed (but should be available upon request). Aloha needs a way to get a passenger count (a tally of booked seats), and access to a flight manifest (detailed flight/seat information). Seats: flights have seats arranged in 40 rows of 6 seats each, numbered to include row and seat designations (eg, row one consists of 1A, 18, 1C, 10, 15, and 17). Seats have an associated price, recline amount (in whole inches), and meal type. Once the seat number is assigned to a seat, it cannot be changed. Other data can be altered. Make up other data as you see fit (pricing, recline, meal type). Customer Confirmations: each confirmation includes a customer name and a six-character confirmation code (alphanumeric, upper-case letters, length of 6). This data can be altered at any time. Once a seat is booked by a customer, the confirmation is added to the existing) seat they have reserved. Each seat, then, either has a confirmation (booked) or not (not yet booked or released from a previous booking) 2 Client Code Requirements Client code must be able to... 2.1 Flight Retrieve individual attributes including the date, origin, destination, flight number Retrieve the passenger count. Retrieve a detailed list of all flight and seat information ("manifest") Retrieve a specific seat by seat number. Retrieve a specific seat by row/column3 Retrieve an array of seat references associated with a specified customer confirmation number 2.2 Seat Retrieve individual attributes including seat number, meal type, price, and recline Make changes to all attributes(?) except the seat number Retrieve the customer confirmation associated with the seat Release the seat, removing the existing customer confirmation 2.3 Customer Confirmations Retrieve individual attributes including the confirmation number and customer name Neither of these attributes can be changed after instantiation . . . . . These can be all the same, throughout the plane, if you'd like. You don't need to generate this code; it's just data passed to you. "We're using OOP; return objects, rather than strings, wherever it makes sense Page 1 of 5 ava . . 3 Design Documentation Before you code, create appropriate design documentation and obtain feedback. Update designs per feedback, then use them during the rest of the development process, then submit them as part of your project. For OOP projects, this would usually include UML Class Diagram(s) and UML Object Diagrams. Free tools to consider: Violet, LucidChart. 4 Code Implementation 4.1 Building Blocks You'll Need . Classes and objects Arrays (2D) "Has a relationships Enumerated types 42 Constructors Where it would be useful to client coders, create at least two constructors for each class, one accepting all pertinent data, and one accepting only the minimum (required) data. In this project, however, both flights and customer confirmations need only a single, complex constructor (do you see why?). Set all defaults in constructors (assume zero or equivalent unless otherwise specified, then make up others that make sense), not in instance variable declaration lines. Do not duplicate any code between constructors (i.e., call the more complex constructor from the less complex one). 4.3 Seat Numbers Provide static methods for (1) turning a row and column into a seat number. (2) turning a seat number into a row, and (3) turning a seat number into a column. Leverage these in your code. 4.4 Preconditions Establish preconditions for the following cases, throwing appropriate exceptions (with helpful, specific, and informative messages) when the preconditions are violated: Empty or null flight number, destination, seat number, or customer name null object references in most cases (allow them in rare cases where they make sense) Origin/destination airport codes not exactly three upper-case characters Confirmation code that isn't exactly six alphabetic characters Invalid date Price at or below $0.00 Seat recline belowo Note: you should not throw exceptions in cases where parameter values would cause runtime errors that would be clearly understandable to client coders, e.g., array out-of-bounds errors *Only regular (rectangular) 2D arrays are to be used in this project: we'll get to jagged arrays later Rather than creating your own date validation, research the use of the SimpleDateFormat class. You'll still want to test to make sure your implementation catches the right types of errors Page 2 of 5 2 . . . 4.5 Notes on the Model Store all the seats in a single, regular (rectangular) 2D array, Create all seats and fill in their attributes when the flight is created; don't postpone seat creation Customers aren't maintained by a separate entity, present or future. The flight and its associated seat array needs to be the sole owner of all data, able to get all the way to seats and their customer data 4.6 Provided interfaces Create class names that are exactly as the interface name shows, minus the interface part. For example, you will create a Seat class that implements the provided Seatinterface. Create constructor parameters as indicated in the comments at the top of the interface file. Make no changes to any interface unless directed to do so by the instructor You may add helper methods to your classes, as necessary Use any enumerated type provided in an interface. 4.7 Other Requirements Create no static methods or variables, except where specifically requested in this handout Static constants are reasonable, of course. Use no class-level public variables. Class-level public constants are okay Use method exposure (public and private") wisely: expose what client code needs, hide internal use methods. Always mark methods and instance data as either public or private, don't take the default. This is supplier code; no main method is part of the deliverables, But do create one to demonstrate the project's basic capabilities (eg, toString results, seat maps, etc.). Accept dates in typical U.S. format (e.8. "02/28/2017"), but separate them into numeric components and store them as numbers. Turn it all back into an attractive MM/DD/YYYY date format when the date is requested. Create an enumerated type for storing the type of meal associated with a seat. Meals can be either Gourmet, Full, or Snack. We don't anticipate that list to change, ever. Write a toString method for each class. Include all data helpful in describing the object's state. Within the created classes, do not converse with the user, there should be no input or output. It is okay for methods to return strings that will be used from client code, however, and to include exception messages which will be seen if client code breaks the rules and misuses your class. 4.8 Style and JavaDoc Follow the Course Style Guide, which is linked in the Reference section of the Modules list in Canvas. Write full JavaDoc notation for the Seat and Customer Confirmation classes. "Pull" means that Xdoclint shows no errors or warnings for these classes. 5 Testing Create a JUnit test class for the Seat and Customer Confirmation classes. Ensure that each method and all state is fully tested. This must include constructors, accessors, mutators, and preconditions. You do not need to test Ul-heavy methods like toString and similar. *Don't use protected in this course; it's usually an unnecessary crutch, causing the same problems as globals. You may also store the data in a better data format, perhaps using what you learn from SimpleDateFormat. Page 3 of 5