Table of Contents Requirements Document3 Use Case Diagram for the Video Library.4 Use Case…

Need your ASSIGNMENT done? Use our paper writing service to score better and meet your deadline.

Order a Similar Paper Order a Different Paper

Table of Contents

Requirements Document3

Use Case Diagram for the Video Library.4

Use Case Descriptions.5

Browse stock.5

Request copy of video.5

Reserve video.6

Extend loan.6

Update catalogue.7

Return copy of video.7

Issue copy of video.8

Collect charges.8

Refuse loan.9

Reservation check.9

Join scheme.10

Identify videos for delivery.10

Identify videos for pick up.11

Class diagram..12

Class Attributes and Operations.14










Video Library System

Requirements Document

A nation-wide chain of video rental shops wants to take advantage of Web technology, in particular, to change the way that it operates. The main change is to allow members to use their Web browsers to look through its stock titles, make reservations and rent videos for delivery to any location within a certain distance from any one of its shops.

Currently, prospective members have to go in person to their local branch of the video chain and pay a joining fee. A member of staff at the branch then issues a membership card, which is used to reserve or rent videos. Members can only rent from the stock available at the branch where they joined.

The owners want to simplify the membership procedure as follows, People can use a Web browser to join the scheme by providing credit card details as well as their postcodes, which allows the company to perform a credit check and locate their home address while the prospective member waits. Once a membership application has been accepted, the member can browse the stock of videos and find out when their choice will be available for rental from the branch nearest to the members home.

The new software system should enable a member to reserve a video in advance or request its delivery if it is available. The local branch would deliver it to the requested address for a small charge. The normal video loan period is 48 hours. The member would either return the video to the branch in person or request its collection for an additional charge, a service that must be asked for when the rental request was made.

The customer also wants the software system to enable members to request an extension to the loan period (by a further 48 hours) after paying an extra charge, but they must be prevented from doing so if they have any videos that are overdue or another member has reserved the video.

Use Case Diagram for the Video Library

The diagram shows a possible use case for the proposed system. You may disagree with parts of the model for example names used or associations between use cases. There is no one correct solution but many possible solutions. You can only apply your own understanding of the UML processes to the problem to produce a diagram. Remember that the only thing that finally makes a model correct is the customer’s signature.

Use Case Descriptions

Browse stock

A member can use this functionality to browse the current stock of the video library. A video librarian will also use this use case as part of the update catalogue use case to browse the catalogue while performing their work.

Request copy of video

A member can use this functionality to request the driver delivers a copy of a video to them.

This functionality requires the system to check that the requested video is not reserved and if it is not to reserve it for the member in question by using the functionality of the reserve video use case which in turn uses the reservation check use case. If either of these fails the functionality of the refuse loan use case is called upon.

Reserve video

This use case allows a member to reserve a video from the system. There is a constraint of only renting the video for a 48-hour period. The functionality of the reservation check use case is employed for this and means that if the video is already reserved for conflicting periods that the reservation will fail.

Extend loan

This use case allows a member to extend the period of loan they have on a video. The same constraint of a 48 period applies to this loan as well as being able to refuse the extension through the refuse loan use case. This use case also uses the functionality of the reservation check use case and can also fail from it if another customer has reserved the video for conflicting dates.

Update catalogue

This use case allows the video librarian to update the stock catalogue; the browse catalogue is used during this use case. This includes adding and removing items from the stock.

Return copy of video

A video librarian uses this use case to log the return of a video from loan. This will happen whether the video was loaned through the web browser or not. If the member is in the store or the video has been returned from the driver the video librarian is the one who will initiate this use case. If the period of loan was extended or the video is being returned late there may be charges to collect. This is catered for through the collect charges use case unless the video was loaned through the web browser when the fees should have been paid in advance by credit/debit card.

Issue copy of video

Only the video librarian again initiates this use case. It is intended to be used for members who are physically present within the shop at the time of renting. The functionality of the reservation check is used to make sure that the member can loan the video.

Collect charges

This use case models the process of logging the collection of charges from a member who is physically in the shop.

Refuse loan

This use case models the behaviour of the system when a loan has been refused.

Reservation check

This functionality is for the use of other use cases to check whether or not a video is currently reserved for a particular date.

Join scheme

This use case shows that both credit card holders and credit agencies can join the shops scheme to allow members to pay for the videos through their credit cards. This is considered to be a constraint for members who are booking videos through the web browser. They are required to pay by credit/debit card before any of their loans or reservations are finally allowed. Once a credit card holder has joined the scheme they are considered to be a member. Credit agencies need to join the scheme so that their systems can be used to collect information about the potential members of the system.

Identify videos for delivery

The driver employed by the video shop uses this use case. He will prepare for a delivery run by using this functionality to determine which videos are to be delivered and to whom.

Identify videos for pick up

This is another use case used by the driver. It will generate a list of videos to be collected and from which members.

Class diagram

The class diagram below shows the classes that have been included in the video library system. The multiplicities of the associations have been included on this diagram but the attributes and operations are shown separately. When either a use case or a class is mentioned it will be italicised for ease of recognition.

An account class has been made a super class of AgencyAccount and MemberAccount to satisfy the Join Scheme use case, which requires credit agencies and members to join through the same procedure. Making a super class for the two different Member types allows the objects to share common code and attributes.

The VideoLibrary class is in place because of the requirement that a member can only rent a video from their local video shop. The intention is that when a user logs on to the web site they are directed to the correct library by postcode or some other determining factor. The use case this is part of is not shown, as it is part of the user interface.

The Catalogue class basically maintains a collection of objects that are videos. This class is used in the Update Catalogue and the Browse Stock use cases. Care should be taken to ensure that a Member does not have the access to change the stock collection in any way, which probably means that a check on the user entering the Catalogue should be included in its operations. All associations to this class are singular so a way of ensuring that only one Catalogue can exist should be incorporated into the system

The loan class will create objects that will make up the collection attribute of each Member. This collection can be traversed for each Member to obtain a complete list of videos on loan. Once again the operations of this class need to ensure that members can only access items that are necessary to the operation of the system from their point of view. This class will be used in the use cases – Collect Charges, Issue Copy of Video, Return Copy of Video.

The Video class is included to model the occurrence of a video within the system. Objects of this class will be linked to members through the loans collection and/or the reservations collection. This class will be used in the use cases – Issue Copy of Video, Return Copy of Video, Update Catalogueand Identify Videos for Pick Up.

The reservation class will model reservation objects that will be accessible through member objects. When the user reserves a video successfully a new reservation object will be added to that member’s reservation collection. This class will be used in the use cases – Identify Videos for Delivery, Reservation Check, Request Copy of Video, Reserve Videoand Extend Loan.

Class Attributes and Operations


Account is a class that is in place to satisfy the occurrence of a Member and a credit agency. This class is a super class of MemberAccount and AgencyAccount. The elements of Account that are common to both types of account are included here. The attributes are to be private to aid encapsulation and the operations are to be declared public allowing access to the attributes through well-defined operations.


The AgencyAccount is a subclass of Account. It inherits the public operations of Account and adds the operations that are specific to an AgencyAccount. The operations that are specific are checkCredit and debitAccount. These are to be public operations allowing the user to access the agencies credit facilities.


MemberAccount is another subclass of Account and is intended to manage the accounts of people who have joined the video shop to rent videos. It handles reserving videos, setting fines and loan details. Once again the attributes are to be private to the class and the operations are to be public allowing access to the attributes.


VideoLibrary is a class that holds details of the shop that is currently being accessed. It allows the user to browse the Catalogue for the correct shop so they can only rent Videos from the correct location. It also maintains the accounts through the accounts attribute, which is intended to be a collection of all accounts for this shop.


The Catalogue class will manage the details of a shops catalogue. It allows the user to view entry details or add and delete items depending on their user status. The user should also be able to select different category of film from using the selectCategory operation.

As all associations to this class are of the one kind this will probably need to be enforced possibly by implementing a singleton pattern.


The Video class is included to model a video within the video library. Its attributes are included for identification and itemising of individual films. The operations allow a user to get and set all the attributes of a film but should probably be restricted to members of staff. Objects of this class will be added to the contents collection of the Catalogue object and will be accessible through that attribute.


The Loan class holds details of individual loans as instigated by members. Its attributes hold information such as the start of the loan period and the amount of time that period before fines can be imposed. The original requirements stated that the loanPeriod was to be for 48 hours. This could mean that as well as being declared private the loanPeriod may also need to be a static final class variable to ensure that all objects refer to the same value. This will not affect the ability to change the variable for all objects but they will all be forced to be the same.


This class holds details of a reservation made by a member. It will contain the name of the film and the date from which it is to be reserved. Operations are supplied for altering this information. It will be accesses through a collection maintained in Member objects.


(i) Do you agree with the class diagrams? Do you think any are missing? If you do not agree with the class diagram redraw as you see fit and justify why it is correct by referring to the UML.

(ii) Even if you agree with the class diagram in principle there is at least one association missing (in my opinion). Can you identify this association and add it to the class diagram? There are clues to it in the text.

(iii) Do the use cases cover all of the requirements of the video library system? If you do not think so you can add some to this document. Be very careful that you are not engaging in requirements creep.

(iv) Are there any attributes or operations missing from this document? If you think so add them to the document.

(v) There is one important element missing from this document that would make it a complete requirements document. What is it and can you produce it?

(vi) In the class description of Catalogue reference is made to a singleton pattern. Research what this means and describe its benefits.