Scenario

The Greater Manchester Combined Authority(GMCA) is responsible for fire and rescue services in the area. GMCA is implementing an automated asset tracking system for fire appliances (also known as fire engines or fire tenders).

GMCA requires a browser-based system to manage all the removable equipment, parts and accessories for each fire appliance. The asset tracking system is to supersede the current manual process of checking the status of all there movable equipment, parts and accessories for each fire appliance at the end of each call-out, and at the start and end of each shift.

An appliance inventory will be maintained, of all the on-board equipment, parts and accessories for each fire appliance, comprising: part name, part type, description and specification. Each fire appliance is identified using its vehicle registration number, as assigned by DVLA. Because there are many copies of some parts each part has a unique ID, known as an asset tag number. The asset tag number is used for tracking, for example, when a particular part is damaged and must be returned. The on-board inventory for each fire appliance lists all the possible removable equipment, parts and accessory types along with their asset tag number.

All fire officers (including apprentice, junior, senior and chief fire officers) can search an appliance inventory. Searching can be performed with asset tag number, part types, part names and keywords from within the description. Only senior fire officers are allowed to add or remove parts or part types in an appliance inventory.

The fleet inventory comprises removable equipment, parts and accessory types available to assign to a fire appliance. These maybe spares to be used in case of damage to fire appliance. Or, they maybe specialist items of equipment for use in certain unusual emergencies (for example, cave rescue equipment not normally carried on fire appliances). Changes to the fleet inventory, are initiated by a request from a Senior Fire Officer. The Chief fire officer (CFO) approves (or declines) fleet inventory changes.

Fire- and Senior Fire-Officers (but not Apprentice-and Junior-Fire Officers) are allowed to exchange parts at the Central Stores Warehouse (CSW), to replace damaged parts. Replacement parts are issued from the CSW by a Store Manager. Occasionally, a Fire- and Senior Fire-Officer need to sign parts back into the CSW. Such Returns maybe because the replacement part is damaged or no longer required. Whenever a new part is installed on a fire appliance an old part is removed and checked-in to the CSW for refurbishment or disposal as scrap.

Senior Fire Officers create Requisitions to purchase new or replacement parts. The Requisitions are sent to store managers. Store Managers then produce a Purchase Order to purchase parts which are sent to Suppliers .Suppliers send goods (the new or replacement parts) and an Invoice to Store Managers. The store managers then reconcile invoices against the purchase orders. Legitimate invoices are then authorised for Payment by the Store Managers.

The Store Managers also handle returned parts which are sent to Suppliers for refurbishment. This time, the Store Managers raise a Refurbishment Purchase Order when Fire Officers return a part. Again, Suppliers send refurbished goods (returned parts) to the Store Managers, who then reconcile invoices and authorise payments.

A Payment to Suppliers is handled by the GMCA Financial Management System (FMS). A message passing interface is used to authorise payments. Each payment authorisation message must include: supplier name, address, phone number, email address, invoice number, order number, authorising store manager name and amount (in GBP ).

Task

Your task is to: Read the scenario in order to draw a detailed a Use Case Model of the system. Your use case model should describe the users view of interaction scenarios with the system. To do this, you should perform the following steps: Identify and name the actors of the system. Indicate primary and secondary actors. Identify and name the use cases in the system. For each actor you have found in the system, identify the use cases for the actor. Consequently, your Use Case Model should include actor and use case relationships.

Next, write a textual use case for each of the use cases you have identified in your diagram. The use cases must include Use Case Title Primary Actor(s)

Secondary Actor(s) [optional] Goal Scope Preconditions Postconditions Main Success Scenario [Numbered steps to perform the success scenario] Extensions [Numbered steps corresponding to the success scenario, that showing branching, exit or exception behaviours].

Your Use Case Model should be consistent with your individual Use Cases. Consequently, you may need to iterate between the model and the use cases to achieve consistency. Adjust the granularity of your use cases to achieve a sensible number.

Draw a UML class diagram of the system. Identify the classes to be included in the diagram. Provide intuitive names for the classes. Where appropriate, show the relationships between classes. Try to include some example of concepts, such as inheritance, association and aggregation. Show methods and attributes in classes, where information is provided. Include method call and return parameters, where appropriate. Where appropriate, include cardinality on the relationships between classes.