Systems Modelling Techniques using UML...Techniques using UML Exercises System Modelling Techniques...

SMTU v8.1

Systems Modelling Techniques using UML Exercises

System Modelling Techniques using UML SMTU-1 v8.1

Exercise 1 – Lending library

Vision Before delving into detailed requirements that prescribe what the system will do, it is a good idea to gather a set of higher-level requirements that assist in scoping the system to be delivered. These high-level requirements constitute the vision for the system and assist in achieving agreement on what will be developed.

A lightweight set of features for the first version of the library application follows:

• It is a support system for a public lending library • The library lends books, audio books, DVDs and videos (collectively known as

loan items) to members. Only people who live within the council’s jurisdiction may join the library. Library members will be enrolled when they join the library. New loan items that are delivered to the library are catalogued before being made available to members

• The library orders new titles and popular titles are delivered in multiple copies. Old loan items are removed when they are out of date, in poor condition, lost or stolen. The actual ordering of titles is part of another project; however, the cataloguing of titles and loan items is part of this project since it helps control what is available to lend

• The librarian is an employee of the library who interacts with the customers (members) and whose work is supported by the system

• A member can reserve a loan item that is not currently available in the library, so that when it's returned or purchased by the library, that member is notified. The reservation is updated when the member checks out the loan item or when it expires

• The librarian must easily maintain information about titles, loan items, members, loans, and reservations on the system

• The system will run on all popular Web browser platforms (Internet explorer, Firefox, Safari, Opera, etc.)

• The system must be easy to extend with new functionality To give some business context; in the first version, members will be able to access the application from any PC within the library to make a reservation or change their personal details. A check will be made when an item is returned to determine whether it is overdue. If an item is returned late the member will be fined and the details recorded on the system. Child members however are not fined for late returns. A child member will become an adult member when they become 16. The first version of the system will not notify members when a reserved title becomes available, nor will it check when a borrowed title becomes overdue. That functionality will be introduced in later versions.

Page 1


Recording of fees for audio books, DVDs and videos will be incorporated in later versions. Future enhancements will also be made to business processes and applications so that members can access the system through supported Web browsers to:

• Check out items and pick them up at a later time • Make reservations • Change their personal details

Page 2


Exercise 2 – Course booking use case

Scenario The Worldwide Training Organisation (WTO) requires a new Course Booking IT system which will support Course Managers, Schedulers and Telesales Clerks in carrying out their tasks. What follows is a summary of the initial requirements for the system, as captured by the WTO business analyst – all functions described are to be included in the system unless otherwise stated.

Course Managers are responsible for the course portfolio and they will use the system to create details about newly offered courses, make changes to existing course details, and delete courses which are no longer offered. They are also responsible for the scheduling of runs of each course.

A Telesales Clerk, when contacted by delegates or company representatives, will take bookings for course runs. When a course run is full, the Telesales Clerk may offer alternative dates. Bookings may be initially provisional or confirmed. Where necessary delegates will contact a Telesales Clerk to confirm their booking, or occasionally to cancel a booking.

Ten working days prior to a course run, the Scheduler will use the system to check for delegates who have not confirmed their attendance. She will then contact them by phone about confirmation and confirm their attendance through the system. If the Scheduler is unable to contact a delegate, or the delegate has changed their mind, their booking is to be cancelled.

To enable Course Managers to make a decision as to whether a course run will take place, the system is to produce and send a daily report of pending courses that are due to start five working days ahead. Depending on the number of delegates booked on the course the Course Manager may decide to cancel the course run. If a course run is cancelled the system will notify the Telesales Clerk who will contact the delegates to advise them of the situation and offer them alternative dates.

For each course run, a venue will be allocated together with one or more lecturers. It is the Scheduler who will allocate the venue from a list of venues usually used by the WTO. The Scheduler will allocate the lecturers to the course run from a list of qualified lecturers. It will not be in the scope of the Course Booking system to manage the list of venues or lecturers.

Following a course run, the Scheduler will amend the status of the course run to ‘delivered’ and will enter the feedback received from both delegates and lecturer.

Occasionally an organisation contacts the Scheduler to ask for a special course run, in preference to using the usual public offering. A special course run will be created in that

Page 1


case, to be attended only by delegates from that organisation. The venue is organised by the sponsoring organisation, in such cases.

Create a UML Use Case Diagram to capture the functional requirements of the system proposed above. You may also make notes about any queries you would have for the business analyst or business users about the system’s functionality.

Page 2


Exercise 3 – Taps ‘n’ Traps vision

Background Taps ‘n’ Traps (T‘n’T) produce a wide variety of quality bathroom and kitchen products, using plastic extrusions and mouldings, together with stainless steel pressings and machined items. They buy-in luxury items such as gold taps as well as other metal fittings and ceramic items. The production processes range from basic forming operations, such as pressing, extrusion, moulding, some machine work (drilling), through to assembly and packing. T‘n’T currently sell their products to builders' merchants and DIY stores. At present the demand for the company's DIY home improvement products is strong.

It has been apparent for some time that the administration and record keeping of the company is somewhat inefficient and error-prone. Auditors have reported that the number of discrepancies between physical quantities in stock and the quantities held on the stores control system is unacceptable. Only 95% of items sampled were within ± 10% by volume of the 'Book Stock' level, and only 20% lay within ± 1%. In the last financial year there were, on average, 12 stock-outs per week. The works director is not satisfied with the controls exercised, particularly over stock movements, and is unhappy with the quality, quantity, and timeliness of management information (MI) available.

The management team have authorised a project to investigate what is required in terms of improved business processes and systems for the running of the company, starting with stores control.

The Stores Project is the first element in the company's plans for the replacement of its aging legacy systems.

Business objectives • Maintain stock records at a level of accuracy of ±1% by volume within the next 15

months • Identify low stock situations in sufficient time to arrange deliveries from suppliers • Facilitate a reduction in stock holding by 5% value within the next 12 months

The Stores Project encompasses 4 distinct areas of the business, each with their own requirements:

Page 1


Goods in from suppliers This procedure is driven by the arrival of a delivery from a supplier, which is checked and the goods (products) moved into the warehouse. A stores person will be responsible for recording the delivery onto the new system after matching the delivery with the original purchase order, which is held on the purchasing system. Stock for quality testing will be held separately (quarantined) from available stock. The stores manager is tasked with deciding which stock items, or ‘products’ will be tested after discussions with the laboratory, manufacturing and purchasing, and this should be recorded on the system. Details of all accepted and rejected deliveries are to be sent to purchasing on a new end of day report.

Issues to manufacturing Items of stock (product) are requested by manufacturing throughout the working day. These are withdrawn from the warehouse and a stores person will record the issue, together with the quantity of each product issued, onto the system after verifying the quantity specified on the manufacturing order, which is held on the manufacturing system. Any stock to be issued that is short (i.e. there is not enough to fulfil the quantity required) is regarded as a ‘stock-out’ and must be recorded for reporting purposes. As a result an end of day ‘stock-out’ report will be sent to purchasing. A new weekly report detailing; opening balance, movements and closing balance for each stock item is required by accounts.

Stock checking The system will produce stock check lists at the start of each working day. The office supervisor (or deputy) will allocate each stock check list to a particular stock checker who in turn will check the actual stock holding of the items on the list. The results will be passed back to the office supervisor who will input the quantities found into the system. Once all stock checks are recorded, the office supervisor will print a daily stock check report for stores management with a copy to audit. The system will also produce an end of day audit report detailing the stock items where a discrepancy was found. Based upon the report, the internal auditors may decide to have a recheck carried out on any deficient items or simply update the quantity by the amount of the discrepancy.

Purchasing Purchasing raise Purchase Orders (POs) with suppliers for items that are running low. They take care to multi-source these items to ensure they can negotiate on price. These POs on the purchasing system will need to be referenced by stores system users but purchasing will not be able to create or update delivery information. However, they will need a facility to create and amend stock item details, together with a stock level enquiry facility. Purchasing is to be notified at the end of each day when stock item

Page 2


quantities are below the min or above the max ‘Book Stock’ level. Items with no movement for 3 months are to be notified as obsolete on a new end of month report.

General requirements 1. One integrated stores system and database to cover the warehouse and stores

office.

2. Integrate the stores system database with purchasing and manufacturing so that up to date purchase order and manufacturing order information is always available in the stores office.

3. No paperwork to be used in internal stores or warehouse processes.

4. All updates to the database (e.g. stock movements, stock balance changes) are to be done as soon as the figures are available.

5. Specifications for the new system are to be captured utilising the Unified Modelling Language (UML) notation.

All other functional areas of the business including sales, marketing, accounts and logistics, are outside the scope of this project.

Produce an initial use case diagram, based on the above vision statement, to clarify the scope of the Stores Project.

Page 3


Exercise 5 – DVD Sales Activity Scenario

Scenario 21st Century DVD Sales receive orders for DVDs from Customers via a web form. The Sales Department checks the Customer details on each Customer order against a Customer file. The Customer’s credit rating is also checked. The DVD catalogue records are then used to check the DVD requests on the Customer order. Any problems are notified to the Customer at this stage by email, and they must re-submit their order. Once a Customer order has been verified as free of problems, it is flagged for processing to the Purchasing Department.

At 3pm every day, Purchasing consolidate the batch of Customer orders received from Sales and check the requirements against stock. If more stock is required, Purchasing raises purchase orders which are then faxed to specific distributors whose details are obtained from a distributor list. Purchasing then add a summary of the orders received to the data used by their Order Forecasting tool.

In the Warehouse, if stock was required, deliveries of the DVDs from the distributors are received and recorded into stock. 3 days before the due date for the order to arrive at the Customer premises, the Warehouse prepares the order for despatch while, at the same time, they advise a courier that a shipment will be ready for picking up.

The order is then despatched to the Customer via the courier company.

Produce an Activity Diagram for this scenario within 21st Century DVD Sales.

Page 1


Exercise 6 – Taps ‘n’ Traps Activity Diagrams

Goods Inwards from suppliers – new requirements 1. Goods Receiving (GR) personnel will check, before starting to unload a delivery,

that the supplier has a delivery note containing our purchase order (PO) number. The GR person will enter the PO number to ensure that we have ordered the goods on a purchase order, and that the goods have not already been delivered. Goods not on order or already delivered will be rejected. When a PO is in a status of ‘complete’ we should no longer accept any deliveries against that PO.

2. Items legitimately delivered against a PO should be registered as delivered in the system. A new marker on the product’s stock record will indicate if it is to be quarantined for quality testing. The Stores Manager will have the responsibility for setting and clearing this marker. Items not marked for quarantine should be moved to their normal allocated store location. The available stock balance is to be updated for these items.

3. Products marked for quality testing are to be held separately from available stock, and the available stock balance should not be updated. If items on the delivery are to be quarantined GR personnel will place them in a separate area of the stores.

4. The laboratory will periodically check the system throughout the day for the arrival of quarantined items and then perform their tests. They will then update each delivery item record tested with their 'accept' or 'reject' decision. An ‘accept’ decision should update the available stock balance. The stock location remains ‘quarantine’ however in all cases.

5. At 4 PM each working day, the Stores Manager will review the status of quarantined items. He will order Stores personnel to move any accepted items into the main warehouse storage and record the transfer. To deal with any rejected items, he will call the supplier to arrange for their removal, and have the goods moved to a ‘returns’ area.

6. Details of all acceptance, quarantine and rejection delivery activity are to be sent automatically to the Purchasing Dept. on a new end of day report.

Issues to manufacturing – new requirements 1. All requests for stock to be issued must have a matching Manufacturing Order

(MO) already on file. This will mean that, when somebody from Manufacturing requests some material(s), we must check that the Manufacturing Order (identified by the Job Number they supply) is on the database, that the stock items they are asking for are listed on the MO, and that the quantities are still

Page 1


outstanding (have not already been issued). Breaking these rules will mean rejection of the whole request.

2. All requests for stock issues must have formal supporting paperwork in the form of an authorised Job Requisition which the production worker will bring with them from Manufacturing. Verbal issue requests from manufacturing staff will no longer be permitted.

3. Once requirement (1) has been met, the stock will be issued. The stores person will identify whether materials need counting or weighing. If the materials requested are a mixture then the stores person will sort the request into weighing or counting sets. Once sorted into sets, the materials can be issued in either order.

4. If material(s) require weighing, the production worker is sent to fetch a factory forklift, directed to the correct material and then to Weighbridge B. The procedure for weighing is to weigh the forklift complete with the material and to subtract the tare weight (painted on the side of each truck) to produce the net weight. The weighbridge operator will update the stock balance and this in turn will create an issue record. This process is repeated for all weighable materials. Once all the materials have been issued, an issue list is created which comprises all the issue records. If any of the materials on the request require counting the following procedure is followed.

5. For materials that require counting the stores person will count them out and adjust the stock balance which creates an issue record which will form part of the issue list once all the countable materials have been issued. If any of the materials on the request require weighing then the weighing process is followed.

6. The production worker will return to the factory with all the issued materials and the issue list.

Stock check – new requirements 1. The stock system must produce the stock check lists at the start of each working

day. Stock items will be selected by the system to appear on lists based on a prioritising algorithm (to be decided). Volumes are expected to be: about 100 stock check items per day, with up to 6 stock checkers available, checking each stock item twice per year.

2. The office supervisor (or deputy) will allocate each stock check list to a particular stock checker, based on their knowledge of staff availability and workloads on the day, write their name on it, and pass the lists to the stock checkers.

Page 2


3. Stock checkers will count each item on the list and record the quantity found in the ‘actual quantity found’ column on the list. Stock checkers will not have access to the current ‘book stock’ database values.

4. Once complete, each list is to be passed back to the office supervisor who will input the results into the stock system. Stock checkers are not to be able to input their own results. The system is to record, on the database, the stock check result – ‘Actual Quantity Found’, ‘Checked By’ or items missed from the check.

5. Any stock items that have a discrepancy (‘Actual Quantity Found’ not equal to ‘Book Stock Level’) are to be added, by the system, to the audit report produced at the end of the day.

6. Based on the audit report, the internal auditors may decide to take action: they can ignore a discrepancy, update the ‘Book Stock Level’ by the amount of the discrepancy or have the item rechecked the next working day. The system is to update the stock database as a result with ‘Action Taken’ and ‘Action Taken By’.

7. Once all stock checks are recorded, the office supervisor is to print the daily stock check report for stores management, copy to audit. The report should list the results of all stock checks performed that day, all auditor decisions recorded, and any items scheduled for checking that day that were not actually checked.

8. As a result of reviewing the stock check reports, there needs to be a facility for stores management or audit to request stock items to be checked on an ad hoc basis. These stock check items are to be recorded on the stock system ready for the next working day's production of the stock check lists.

Page 3


Exercise 7 – Hospital appointment class diagram

Scenario 1 A patient may make an appointment to seek medical advice on a face to face basis with a doctor. Doctors are allocated appointment slots, which are blocks of time within a clinic session, held in one of the hospital’s clinics. A clinic session is in effect a working day, blocked out weeks in advance and each clinic session consists of 18 appointment slots of 20 minutes duration.

When a patient wants to make an appointment they are offered one of the appointment slots allocated to the doctor they need to consult. If a clinic session is cancelled, all appointments and slots for that session are also cancelled and new, alternative appointments have to be made.

Following the appointment and diagnosis, any operations required by a patient are eventually scheduled for a theatre session in one of the hospital’s operating theatres. Occasionally operations have to be re-scheduled to another session. There may be up to five operations in a theatre session. Each operation is normally performed by one doctor, but on occasions 2 doctors are required.

Page 1






In the following additional narrative you will find the opportunity to modify your original diagram to include examples of: multiple relationships, reflexive relationships, resolution of m:n relationships and the placing of association constraints.

“If 2 doctors perform an operation one will lead the operation, and must be qualified, while the other assists. Senior doctors are assigned as general mentors to junior doctors, and the hospital requires a record of these arrangements, as part of their doctor development plans.

As doctors are qualified to perform only certain types of operation, the hospital wishes to record which operation type each doctor is qualified to perform, and when they qualified.”

Page 1






If 2 doctors perform an operation one will lead the operation, while the other assists. Senior doctors are assigned to mentor junior doctors, and the hospital requires a record of these arrangements, as part of their doctor development plans.

As doctors are qualified to perform only certain types of operation, the hospital wishes to record which operation type each doctor is qualified to perform, and when they qualified.

In this exercise, make a note of at least one example of aggregation and one of composition, using the model produced so far. Also, based on the following additional narrative, make a note of an opportunity to represent specialisation / generalisation.

“At each operation, in addition to the doctor(s), there will be one anaesthetist and one theatre nurse assisting. Many of the attributes that the hospital holds about their medical staff are the same.”

Page 1


Exercise 9 – Rail tickets

Scenario The Magic Rail Travel Booking Company (“MagicCo”) is to establish a number of issuing offices around the country which will use a new ticketing system. These issuing offices are to be staffed by specialist Booking Agents who can issue a range of types of rail ticket to personal or telephone callers. There is also to be an internet facility available for use by corporate customers.

Ticket sales requirements 1. Customers can book 1 or more journeys by rail using this system. A journey

consists of 1 or more legs. One ticket is issued to cover all legs on a journey.

2. Tickets for journeys by personal or telephone callers will be issued by the Booking Agent concerned, an invoice raised and paid for immediately. The system will record the booking data (including date, customer details, amount due and payment method) and print the ticket(s).

3. Business customers of MagicCo will have to register by setting up an account. This is to be done by a Business Account Consultant who enters and maintains business account details, including the named employees who will be allowed to book journeys through the system.

4. Employees of registered business customers (i.e. they have an account with MagicCo) will be able to book journeys over the Internet and the system will issue an e-ticket to the employee for each journey. The system is to record booking information in a similar way to requirement (1).

5. At the end of each month an Invoice will be raised by the system for each business account to cover all the journeys purchased in that month. A copy of the invoice will be sent to the business customer and payment is to be immediately initiated by sending a direct debit instruction to the BACS system.

6. Once the BACS system notifies MagicCo that payment has cleared, the ‘paid’ field and the ‘date paid’ field are to be automatically updated in the invoice details.

Exercise Draw a Domain Class Diagram that captures the business information given in the

scenario above. You may make reasonable assumptions where necessary; for example where the multiplicity of relationships is not mentioned explicitly.

Page 1


Exercise 10 – Bakery class diagram

Scenario A large bakery company maintains details of the products it manufactures (bread, cakes, rolls, biscuits etc.) and the quantities of the various ingredients used in each product. Each ingredient (flour, milk, sugar, chocolate etc.) is used in many products.

The company's buyers place orders for the ingredients with a range of suppliers. In order to be able to negotiate the best prices they take care to be able to multi-source their ingredients, by keeping records of which suppliers can supply which ingredients.

The company's stores department takes responsibility for recording each supplier delivery, and the ingredients and quantities on each delivery. For orders involving large quantities there may be multiple deliveries to satisfy an order.

The bakery has many machines of various types (they currently have 6 ovens, 10 mixers, 4 slicers etc.) They hold details of which machine types are used in manufacturing which products. Most machine types are used in the manufacture of several products.

The bakery schedules production runs for each product. When they create a production run they allocate a number of individual machines to it. Typically each machine participates in hundreds or even thousands of production runs during its service life.

Produce a class diagram for the bakery.

Page 1


Exercise 13 – Expense claim

Scenario When working on assignments around the country employees often have to pay bills – for example hotel bills, restaurant bills, taxi fares, and train fares. Employees must always obtain a receipt once they have paid a bill as proof of the expenditure. A few expenses, such as tube fares paid by Oyster Card, where receipts are not issued, will be accepted with no proof. When checking out of the hotel, the receipt obtained may detail a number of expenditure items and items such as phone calls and newspapers will be summarised. The employee must use the standard company expense form for their claim to be accepted and must submit the claim within two months of incurring the expense.

To make a claim employees should download the latest expense claim form (a spread sheet) from the intranet. Based on receipts from service providers, employees complete the spreadsheet claim form using one line per claimable expense. Every expense item claimed must be allocated to a pre-set category of expenses. Each receipt is numbered and referenced to the expense form and attached in numerical order.

The completed expense form is submitted by e-mail to Finance. As well as the e-mail, a hard copy is printed off and is sent, by post, to Finance with all receipts attached. The hard copy is signed by the employee before posting.

Once the hard copy and the electronic copy have both been received, the submitted expense form is registered in a log and reviewed by Finance. If the expense form has not been completed correctly, for example not signed, it will be marked as ‘rejected’ and the employee will be informed.

If the claim has been completed correctly, the claim is checked by Finance for adherence to the company’s expense policy. Claims that appear to deviate from the policy will be marked as ‘queried’ by Finance, pending authorisation by the employee’s Line Manager.

After the Finance review, claims not rejected are forwarded electronically to the employee’s Line Manager for approval. She may approve the claim or not, and she may want to discuss the claim with the employee, but in any case her decision is communicated to Finance and to the employee.

If a claim is not approved by the Line Manager for any reason, or Finance reject the claim, the employee may correct the claim and re-submit it via e-mail to Finance. The claim then becomes ‘registered’ again. Alternatively the employee can withdraw the claim, notifying Finance who update their log accordingly and return the physical documents.

Page 1


Approved expense claims received from Line Managers by 3pm Tuesday afternoon will be cleared automatically for reimbursement by the IT system and the order will be made by the system to the company’s bank to transfer the funds into the employee’s nominated bank account by Tuesday of the following week. The claim record is updated by the system to ‘reimbursed’ after the transfer date.

Claim information is held for 6 years after reimbursement under HMRC rules, after which they are purged from the system, and the physical documentation destroyed. Withdrawn claims are also purged at this time.

1. (a) Draw an Activity Diagram that represents the processing of an expense claim. Only include actions that are significant to the business.

(b) (optional) Add Object Flows to your model to depict state changes to the Expense Claim object.

2. Draw a Domain Class Diagram that captures the business information contained in the scenario. Make any reasonable assumptions, for example with respect to multiplicities that are not explicit.

3. Draw a State Machine Diagram to model the lifecycle of a typical Expense Claim object.

Page 2


Exercise 14 – Course Booking State Machine

Scenario The Telesales Office of the Worldwide Training Organisation fields enquiries from clients regarding scheduled courses and the availability of course places. If the client is uncertain about the availability of their employees for attending the course, then a provisional booking can be made and held for a period of 48 hours. Within this period of time the client must confirm the booking or the provisional booking will be deleted (purged). If the client calls to cancel a provisional booking it is simply deleted.

Two weeks before the course is due to commence the administration section send out joining instructions for each delegate to inform them of course start times and details of the venue, and invoice the client. Clients may choose to cancel a course booking at any time, prior to the event starting. However, if the cancellation falls within two weeks of the scheduled start date, the client will still be invoiced for the course place.

Occasionally, when the trainer meets the delegates on the first day of the course, it is discovered that a delegate has failed to show up. In this circumstance the booking is marked as a “no show” and the client is notified. If the delegate does show up, the booking is marked as ‘registered’

All delegates who complete the course are issued with a certificate of successful course completion on the last day, and the booking is updated to show that the delegate attended. However, delegates who withdraw from the course prior to completion (e.g. due to illness), do not receive a certificate and their withdrawal is recorded on their booking. All booking records are deleted (purged) after two years.

Draw a State Machine Diagram to model the lifecycle of a Course Booking.

Page 1


Exercise 16 – Use case description for lend item

Lib03 Lend Item Brief Description: A member brings the item, or items, to be borrowed to the

counter. The librarian retrieves the member details and loan items from the system. The library lends the selected item to the member and the loan is recorded. If the member has a reservation the librarian retrieves the reservation from the system and fetches the item to be borrowed, the loan is recorded and the reservation is updated to fulfilled. A member may not have more than the maximum number of items on loan from the library at any one time. If the member has any outstanding fines, these must be paid in full before an item can be borrowed.

Actor(s): Librarian on behalf of the member. Trigger(s): Member selects items to borrow or collects a reserved item. Pre-conditions: The loan item status is “Available”. The librarian is logged on

to the system and has selected the “lend items” option.

Main Flow: 1. Librarian enters the member’s membership number into the system. 2. «include» use case Lib06 Validate Member. A1 3. System checks that member has no outstanding fines. A2 4. System checks number of “Active” loans for member. A3 5. For each loan item up to the maximum number of loan items. A3 6. System prompts “Please identify loan item”. A4 7. Librarian enters the loan item number. 8. System retrieves loan item copy number, title name and author. A5 9. Librarian confirms loan item is to be lent to member.

10. System creates a loan and associates it to the member and loan item.

11. System sets loan item status of loaned item to “On Loan”. 12. Librarian confirms more loan items. 13. Use Case Ends.

Main Flow Post-conditions: An “Active” loan is created for each loan item borrowed. The status of each loan item lent is set to “On Loan”.

Page 1


Alternative Flows A1 Person not a member

1. Use case ends. Alternate Flow Post-conditions: Loan not created.

A2 Member has outstanding fines

1. System prompts “Member has outstanding fines.” 2. Outstanding fine «extend» by use case Lib11 Collect fine payment. A6 3. Return to main flow.

Alternate Flow Post-conditions: All outstanding fines “Cleared”.

A3 Maximum number of items on loan reached 1. System prompts “The maximum number of items that can be

borrowed has been reached.”

2. Return to main flow at “Use Case Ends.” Alternate Flow Post-conditions:

A4 Member has reservation

1. Librarian enters reservation number. 2. Reserved title «extend» by use case Lib13 Update reservation. A7 3. Return to main flow at “System retrieves loan item copy number…”

Alternate Flow Post-conditions: Reservation status set to “Fulfilled”.

A5 Loan item not found 1. System prompts “Loan item not found.” 2. Return to main flow at “For each loan item…”

A6 Outstanding fines not cleared.

1. Use case ends. Alternate Flow Post-conditions: Loan not created.

A7 Reservation not found

1. Return to main flow at “For each loan item…”

Extension Points: Outstanding fine, Reserved title

Requirement References: Lib06, Lib11, Lib13

Page 2


Revised lending library use case diagram

Page 1


Activity Diagram for Lend Item Use Case

act Lend Item

Page 1


Exercise 17 – Use case description for record product delivery

TnT09 Record Product Delivery Brief Description: All deliveries from suppliers are to have a matching purchase

order (PO). The supplier’s delivery details must contain our PO number otherwise the store person will reject the delivery. Only outstanding (undelivered) items on a valid PO may be accepted. When a PO is in a status of “complete” (set by purchasing dept.) we will no longer accept any deliveries against that PO. For each accepted delivery we must make a record of the delivery and all the delivered items on it and update the product’s quantity available and purchase order item quantity outstanding.

Actor(s): Store person. Trigger(s): Supplier’s delivery vehicle has been unloaded. Volume/Frequency 8 per hour peak. Pre-conditions: Products being delivered must be in a state of ‘Active’. Store

person has selected the “Record Delivery” option.

Main Flow 1. Store person enters the purchase order number referenced on the

supplier’s delivery note into the system. A1

2. System retrieves the purchase order, associated ‘Outstanding’ or ‘Part Delivered’ purchase order items, the supplier details and prompts “Please enter delivery details”.

A2

3. Store person enters delivery details. 4. System creates the delivery and associates it with the supplier and

purchase order being fulfilled.

5. For each ‘Incomplete’ purchase order item comprising the purchase order: 6. System prompts “Please enter delivered quantity”. 7. Store person enters the quantity unloaded. 8. System creates the delivery item and associates it to the delivery,

the product being replenished and the purchase order item the delivery item satisfies.

9. System decrements the quantities outstanding attribute for the purchase order item by the delivery item quantity.

A3

10. System sets the purchase order item status to ‘Complete’ when the quantity outstanding attribute for purchase order item equals zero.

A4

11. System indicates if quarantine marker on product is set for the delivered item.

A5

Page 1


12. System increments the product balance attribute by the delivery item quantity.

13. System sets the delivery item status to ‘Accepted’. 14. System sets the delivery status to ‘Accepted’ and prompts “No more

purchase order items for this purchase order.”

15. System notifies purchasing that the purchase order is now complete if all purchase order item status values have been set to ‘Complete’.

16. Use Case Ends. Main Flow Post-conditions:

Product remains in a state of ‘Active’. The purchase order will be changed from ‘Authorised’ to ‘Part Delivered’ or remain as ‘Part Delivered’ when there are still outstanding purchase order items for it. When there are no more outstanding purchase order items on a purchase order the system will notify Purchasing that the purchase order status requires setting to ‘Complete’. For each delivery a delivery will be created together with delivery items for each incomplete purchase order item delivered.

Alternate Flows A1 Purchase order number not found 1. System prompts “Purchase Order details not found.” 2. Use Case Ends.

Alternate Flow Post-conditions: Delivery rejected at outset. Delivery vehicle turned away.

A2 Purchase order found but marked ‘Complete’ 1. System prompts “This purchase order is complete. No further deliveries are

required.”

2. Use Case Ends. Alternate Flow Post-conditions: Delivery rejected at outset. Delivery vehicle turned

away.

Page 2


A3 Quantity of product delivered greater than the quantity outstanding 1. System prompts “The quantity you have entered is greater than the quantity

outstanding. Please return the extra items to the supplier.”

2. Store person enters action taken details. 3. System sets delivery item quantity attribute to purchase order item quantity

outstanding and then sets purchase order item quantity outstanding to zero.

4. System creates reject note for excessive quantity. by use case TnTRejDev (Create reject note).

5. Use Case Continues. Alternate Flow Post-conditions: None.

A4 Quantity outstanding attribute for purchase order item greater than zero 1. System sets the purchase order item status to ‘Part Delivered’. 2. Use Case continues.

Alternate Flow Post-conditions: None.

A5 Product marked for quarantine 1. System prompts “This product has been selected for quality testing. Place

the items in the QA Check bay.”

2. Store person acknowledges prompt. 3. System set delivery item status to ‘Quarantined’. 4. System informs laboratory that quarantined products are ready for

checking.

5. Use Case continues at next ‘Incomplete’ purchase order item. Alternate Flow Post-conditions: Delivery item status set to ‘Quarantined’.

Extension Points: Too much delivered

Requirement References: TnTGIfromSupp01, TnTGIfromSupp02,

TnTGIfromSupp03

Page 3


Main flow description for Lend Item

MFLib03 Lend Item Brief Description: A member brings the item, or items, to be borrowed to the

counter. The librarian retrieves the member details and loan item(s) from the system. The library lends the selected item(s) to the member and a loan is recorded for each item lent.

Actor(s): Librarian on behalf of the member. Trigger(s): Member selects item(s) to be borrowed.

Main Flow: 1. Librarian enters the member’s reference into the system. 2. System retrieves matching member’s details. 3. For each loan item being borrowed. 4. Librarian enters the reference of the loan item. 5. System retrieves matching loan item details. 6. Librarian confirms item to be loaned. 7. System records loan. 8. Use Case Ends.

Page 1


Exercise 4 – T‘n’T record product delivery

MFTnT09 Record Product Delivery Brief Description: When a delivery is received from a supplier it is checked and

the goods (products) moved into the warehouse. The delivery is recorded after matching the delivery with the original purchase order, which is held on the purchasing system. Stock for quality testing will be held separately (quarantined) from available stock.

Actor(s): Store person. Trigger(s): Supplier’s delivery vehicle has been unloaded.

Main Flow: 1. Store person enters the purchase order number into the system. 2. System retrieves the purchase order details. 3. Store person enters delivery details. 4. System creates the delivery. 5. For each purchase order item comprising the purchase order: 6. Store person enters the quantity unloaded. 7. System updates the product balance by the amount delivered. 8. System highlights any product to quarantine for testing. 9. Store person confirms end of delivery details input 10. System displays delivery details 11. Stores person confirms OK 12. Use Case Ends.

Page 1

DG_FC_ExercisesHAND_01_Ex 1 Lending_Library_VisionHAND_03_Ex 2 Course_Booking_Use_Case_ScenarioHAND_05_Ex 3 Taps_n_Traps_Vision_StatementHAND_09_Ex 5 DVD_Sales_Activity_Diagram_ScenarioHAND_11_Ex 6 Taps_n_Traps_ADsHAND_13_Ex 7 Hospital_Appointment_Class_Diagram_Scenario_1HAND_15_Ex 7 Hospital_Appointment_Class_Diagram_Scenario_2HAND_18_Ex 7 Hospital_Appointment_Class_Diagram_Scenario_3HAND_20_Ex 9 Rail_Tickets_Class_Diagram_ScenarioHAND_22_Ex 10 Bakery_Class_Diagram_ScenarioHAND_26_Ex 13 Expense_Claim_ScenarioHAND_30_Ex 14 Course_Booking_State_Machine_ScenarioHAND_34_Ex 16 Lending_Library_Use_Case_Description_for_Lend_ItemHAND_35_Revised_Lending_Library_Use_Case_DiagramHAND_36_Activity_Diagram_for_Lend_Item_Use_CaseHAND_37_Ex 17 Taps_n_Traps_Use_Case_Description_for_Record_Product_DeliveryHAND_07_Lending_Library_Main_Flow_Use_Case_Description_for_Lend_ItemHAND_08_Ex 4 Taps_n_Traps_Main_Flow_Description_for_Record_Product_Delivery

Systems Modelling Techniques using UML...Techniques using UML Exercises System Modelling Techniques...

Documents

Transcript of Systems Modelling Techniques using UML...Techniques using UML Exercises System Modelling Techniques...