You are required to develop a series of design models for a software-based system that assists in the management of air traffic control information. The system is to be called Flight Management System (FMS). The remit for FMS is described informally below: FMS shall assist with the management of flight plans and flight strips. A flight plan is created whenever a pilot wishes to fly within controlled airspace. A flight strip contains the information that an air traffic controller requires in order to manage aircraft within the sector of controlled air space that they are responsible for. Within the FMS both flight plans and flight strips will be digital. A pilot shall interact with the FMS in order to create a flight plan while an air traffic services assistant (ATSA) shall interact with the FMS in order to create flight strips. Each time a pilot wishes to create a flight plan they shall be required to provide a six digit PIN. Only the pilot that intends to make a flight can create the associated flight plan. The FMS shall manage a collection of pilot records which record: a pilots unique identifier, known as a PID; the PIN associated with the PID; the pilots name; contact phone number; a list of airports that the pilot is certified 1

to take-off from and land at using the International Air Transport Associations (IATA) location identifier format, i.e. a unique 3-letter code, e.g. EDI (Edinburgh), DXB (Dubai International), KUL (Kuala Lumpur International). A flight plan shall require the following information: a unique identifier for the flight plan, known as the FPID; the pilots PID; the codes (IATA format) for the planned departure and destination airports; an expected departure time (EDT). The FMS shall record the following information for each airport: its IATA code; its full name; the name of the nearest city to the airport; its location, i.e. latitude/longitude coordinates. Once a flight plan has been successfully created a corresponding flight strip must be created before the flight can depart. The role of an ATSA is to interact with the FMS in order to create a flight strip for each flight plan. The FMS is required to allow an ATSA to process multiple flight plans in a single session. Before a session starts a ATSA is required to log into the FMS using a six digit PIN. Each ATSA has a unique identifier, known as an AID. FMS shall manage a collection of ATSA records which record a ATSAs AID and PIN. To end a session, an ATSA is required to logout of the FMS. During a session, when an ATSA requests a flight plan to process, the FMS presents both the flight plan details along with the available routes. The FMS shall use external software called the Route Finder System (RFS) to find a list of available routes between the departure and destination airports. As inputs from the FMS, the RFS requires the IATA codes for the departure and destination airports along with the EDT. It is the responsibility of the ATSA to decide which of the available routes, supplied by through the FMS from the RFS, is allocated to the flight, i.e. added to the flight strip. Note that it is possible that no routes are available for the given flight plan. A flight strip shall contain the following information: a unique identifier for the flight strip, known as the FSID; the departure airport (IATA code); the destination airport (IATA code); the allocated route; the EDT; a status flag that indicates if a flight strip is active or inactive. On creation, a flight strip is active. Note that the FMS is part of a larger system-of-systems. At the end of a flight another system will set the flight strip to be inactive. Daily at 23:59 (GMT), the FMS shall send a list of the inactive flights strips (i.e. their FSID along with departure and destination airports (IATA codes)) to an external Flight Archive System (FAS). The FMS shall then delete the inactive flight strips and their associated flight plan records. Based upon the informal description above, you are first required to define and model a set of requirements for the FMS. Secondly, you are required to developed a set of design models that achieve your requirements. Thirdly, you are required to derive a set of test case scenarios using aspects of your design models. Guidance: the FMS needs to robust, e.g. it needs to be able to deal with erroneous or inconsistent inputs. Your requirements and design models should reflect this. The assessment of Coursework-1 will take into consideration the robustness of your design. Specific Tasks: T1: State explicitly any assumptions that you have made about the capabilities required of the FMS which have not been made explicit above. In addition, state explicitly any expectations you have made about the environment in which the FMS will operate, e.g. expectations of the users and the external systems, which have not be made explicit above. Guidance: you are not being asked to restate the above description. You are being asked to make explicit any gaps that you have identified in the description above that are relevant to your design of the FMS, and importantly how you dealt with them. T2: Develop a set of functional and non-functional1 requirements. Guidance: your require- ments need to be sufficiently precise and complete that a third party would be able to produce 1Two non-functional requirements will be sufficient. 2

a design for the FMS. Ensure that your requirements cover how bad behaviours should be dealt with as well as good behaviours. Moreover, for all requirements you should adopt a simple and uniform style see the lecture notes entitled Software Design: Requirements Engineering (see Week 1 on Canvas). T3: Develop a Use Case model for the FMS that includes at least base use cases for: Create Flight Plan. Create Flight Strip. Archive Flight Strip. Guidance: you may require additional base use cases and auxiliary use cases (i.e. inclu- sion/extension use cases). Your Use Case model should include ONE Use Case Diagram and Use Case Specifications (textual descriptions) for all your use cases. Guidance: dont forget to specify alternative flows. Any auxiliary use case(s) that you choose to introduce should appear within the Use Case Diagram and their Use Case Specifications should also be defined. T4: Provide a traceability matrix that links all your use cases with your functional requirements. Guidance: see lecture notes on UML Use Case Modelling (Part 1) (see Week 2 on Canvas). (T2 & T3). T5: Develop a Class Diagram for the FMS include all the classes that will form part of the FMS software, and ensure that you include their associations. Guidance: RFS and FAS are exter- nal to FMS. If you chose to include them in your diagram then be sure and show the boundary between them and the classes that define FMS. T6: Develop Sequence Diagram(s) based upon your Use Case Specifications for Create Flight Plan, Create Flight Strip and Archive Flight Strip (T3). Guidance: ensure that your model captures the alternative flows. Note that an alternative flow can be represented as a separate Sequence Diagram, or using conditional blocks within a single diagram, i.e. referred to as interaction frames in the lecture entitled UML Sequence Diagrams (see Week 4 on Canvas). Ensure that your Sequence Diagram(s) are consistent with your Class Diagram. T7: Develop Activity Diagram(s) based upon your Use Case Specifications for Create Flight Plan, Create Flight Strip and Archive Flight Strip (T3). Guidance: ensure that your model captures the alternative flows. T8: Develop a State Machine Diagram that models the lifetime of a flight from the perspective of the FMS, i.e. from the creation of a flight plan through to when it is deleted along with its flight strip. Guidance: ensure all transitions represent actions/events, e.g. pilot supplies ... etc. Ensure also that states represent key moments, e.g. flight plan exists, etc. T9: Derive a set of scenario test cases from either your Sequence Diagram(s) or Activity Dia- gram(s) (T6 & T7). Guidance: for background on scenario test cases, see the lecture notes entitled Software Verification: A Life-Cycle Perspective (see Week 7 on Canvas). You should use the specification templates (i.e. Use Case templates) given on the Canvas course pages (see the UML Related Material module). UMLet is recommended for developing your UML diagrams, however, you may use an alternative drawing tool if you wish. But please note that hand- drawn UML diagrams are not acceptable. 3

3 The structure and content of your submission for Coursework-1 Your submission should take the form of a self-contained report (MS Word or PDF format)2. Your report should contain page and section numbers, as well as a table of contents. Your report should include: i) a FRONT PAGE that is a signed Student Declaration of Authorship form3, and ii) 10 sections corresponding to the following 10 deliverables: D1: Your assumptions and expectations. Each assumption and expectation should be numbered. [T1] (10-marks) D2: Tables containing your functional and non-functional requirements, again using a clear num- bering scheme. [T2] (12-marks) D3: Your Use Case Diagram for the FMS. [T3] (10-marks) D4: Specifications (textual descriptions) for the base use cases within your Use Case Diagram, including any auxiliary use cases. [T3] (10-marks) D5: Your traceability matrix. [T4] (4-marks) D6: Your Class Diagram for your FMS design. [T5] (10-marks) D7: The Sequence Diagram(s) you derived from your Use Case Specifications for FMS. [T6] (10-marks) D8: The Activity Diagram(s) you derived from your Use Case Specifications for FMS. [T7] (10-marks) D9: Your State Machine Diagram. [T8] (10-marks) D10: Your set of test case scenarios. [T9] (10-marks