Outline use case represents and justification of design

Outline of the assessable outcomes1.       IntroductionThis is a document that is aimed at the manager of the overall project. It should contain a highlight about the background and an outline of business and information systems analysis & design techniques used in this report.

10 marks2.       The system requirements analysis and design2.1   The system context analysisCreate a use case model (diagram) which scopes the ILMS functions, with written explanations of what each use case represents and justification of design decision.                                                                                                       20 marks2.

2 The system behaviour analysisSelect ONE use case from the use case model in Section 2.1 and further analyse its business activities and the involving stakeholders. Create an activity model (diagram) with written explanations and justification of the design decision.                15 marks2.3 The data model designCreate an appropriate class model (diagram) to illustrate the design of data structure for ILMS.

Provide written explanations of the classes by using CRC and justification of the design decision.                                                                              20 marks2.4 The functional workflow designSelect ONE use case from the use case model in Section 2.1 and pick the relevant objects from the class model in Section 2.3. Create an appropriate sequence model (diagram) to represent the dynamic communication aspect of the class diagram that you have produced. With written explanations of what each component of the diagram represents and justification of design decision.

15 marks2.5 The system’s components designCreate an appropriate component model (diagram) to represent the reusable patterns of the system’s functions. With written explanations of what each component of the diagram represents and justification of design decision.                            10 marks3.       Conclusions and RecommendationsThis section should contain information, including summary of the report, difficulties you encountered, any assumptions you made and what you have learnt from this piece of work, highlighting suggestions for the future improvements.

10 marks1. IntroductionThis document specifies the designs for a new automated library system, which will become a central part of the University’s activities, assisting in teaching, learning and research. The system will run 24/7, serving staff and students, as well as members of the public.

This document includes several sections with diagrams, each describing a different aspect of the system’s design. The system context analysis identifies the use cases of the system, and describes them in the use case diagram. The system behaviour analysis provides an activity model for one of the use cases discussed in the previous section, as well as the accompanying use case description. The data model design section includes a class diagram for the system, as well as a CRC card for one of the classes described. The functional workflow design includes  a sequence diagram, which displays a use case and the classes and methods involved in it. The component design diagram groups together functionality.2 System requirements analysis and design2.1 System context analysis and designThe “Check out book” use case is only acted on by the library member actor, but extends the “Refuse loan” use case.

Checking out the book represents the end goal for the library member, and if successful then the book will be withdrawn. Only a member of the library should be able to check out the book, meaning no other actors are needed, and extends refuse loan as the only time this use case would be used is when a library member has already tried to withdraw a book. Other use cases for the library member include “Place book request” and “Return book” which include the “Check reservation queue” use case. These are acted upon only by the library member as none of these actions can be completed without anyone else. These use cases include checking the queue as if there is an issue with the reservation queue, then the use case cannot be completed.

The “check reservation queue” use case itself involves checking the system to see if the book has been requested and reserved by another library member. Also including this use case is the “extend loan” use case, which includes it for the same reason, but is not acted upon by the library member. This is because it is not the library member that decided to extend the loan or not, it is the system.Library members can also use the “pay fines” and “search for books” cases.

Again, no other actors can use these cases. Paying fines is specific to each member, and means giving the system back any late fees that have been charged to the library member. Search for book involves the library member to search the system to reveal information to the user on if the book is available, out on loan, missing, etc.

All human actors, i.e. the library members and the junior/senior librarians can “view account” and “login/ logout”. These are specific to the individual user, and allow that user to see information relevant to them. For example, a library member could see the books they have withdrawn and the fines they have withstanding, whereas a senior librarian could see these details for all the library members.The senior librarian can also “Generate reports” and “approve recommendations”. Generating reports extends 2 other use cases, “popularity report” and “fines report”. The latter are two types of report and therefore cannot be done without generating a report.

These use cases can only be accessed by a senior librarian as they would not have to be done often and it is important they are done correctly.The approve recommendation use case is included by the “recommend book” use case, which is also acted upon by an internal library member. Recommending a book cannot be done without the recommendation being approved by the librarian, so therefore recommend book must include approve recommendation.The timer actor has one main job, which is to generate reminders based on certain extended cases that will be sent to any library member that fits any of the criteria. The extended cases for “generate reminder” are “book due”, “fees due”, “membership renewal” and “book available”. For example, a library member that has run out or is close to running out of membership will be sent reminders from the generate reminder use case at intervals logged by the temporal trigger actor. Only the temporal trigger actor can access this use case as the reports are generated automatically, and the trigger keeps time of when the reports need to be processed.The “HR” and “RISIS” actors have access to the “update account” use case, which involves changing the details on someone’s account such as closing a no-longer used account or changing a password.

No other  actors have access to this use case as being able to alter other user’s details could cause major disruption in the system. The HR actor is representative of a 3rd party support line which could help a person in need, and the RISIS actor represents a library member who is logged into the RISIS portal and is changing details in their account manually.2.

2 System behaviour analysisActivity Diagram: a graphical representation of workflows of stepwise activities and actions. (Bennett, McRobb and Farmer, 2018)The use case being shown in the activity model is the extend loan use case.The extend loan process is made up of a set of activities performed by the library member, and some other activities performed by the library system. The library member initialises the activity by requesting a loan.

The checks for each of the possible outcomes are performed by the library system using 5 different decision nodes. These each represent the 5 conditions that must be met in order for a loan to be allowed to be extended; the number of extensions of the book must be less than or equal to 7, the user must have at least 30 days of their membership remaining, the user must have no fines due, the book must not be in the reservation queue for someone else and the book cannot be overdue.At each stage, if the condition is not met, the library system passes back to the library member with a suitable message to inform them as to why the extension has been refused. In the case that the request makes it past all 5 of the decision nodes, 3 functions are called and executed in order to update the system accordingly.These will update the system with the date that the book is now due given the extension.

They will calculate the total loan time and increment the renewal counter. A receipt is passed back to the library member and they are informed that their extension was successful.The behaviour analysis diagram allows us to go into depth of one us case and analyse the necessary functions it must perform. They allow us to model computational processes and show the flow of data within the use case between the library member and the library system.

All the responses from the library system are modeled and the conditions that give the responses so that when implementation takes place, the structure and outputs are known.2.3 Data model designA class model diagram has been created to show the proposed data structure for the ILMS. An example Class Responsibility Collaborator (CRC) card has also been included for the ‘Book’ class and it’s ‘switchResStatus’ function.Class Inheritance Tree:Library MemberGeneralPublicInternal Member –  abstract class for a university memberUnderGradStudent – loan limit of 10, fine rate of 0.02PostGradStudent – loan limit of 10, fine rate of 0.

02Staff – Reminder – Sent to usersBookDue – Reminder for a book being dueFeesDue – Reminder for outstainding feesMembershipRenewal – Reminder for membership expiryBookAvailable – Informs a user when a requested book is availableReport –  provides information StatsOfReservation – contains info and template for report about a reservationStatsOfLoan –  contains info and template for report about a loanBook – stores data about a book that the library ownsCopyOfBook – relates to a specific copy of a book the library owsRecommendation – recommends a book to an internal memberReservationArchive – keeps a history of reservationsReservation – allows a member to reserve a bookArchiveOfLoan – keeps a history of loadsLibraryMember: It was decided that inheritance was a natural way to deal with the different subcategories of library users. This abstract parent class contains all the methods and variables that are common to all users.GeneralPublic: this and InternalMember are the children classes of LibraryMember. It is necessary to differentiate between these two types of user because public members of the library are required to renew their membership.InternalMember: InternalMember covers all users of the library who are members of the university, and therefore needs to store the department they belong to. This class is also abstract; only the child classes are actually instantiated.UnderGradStudent/PostGradStudent/Staff: these classes, which are children of InternalMember, simply have different fineRates for late books and different loanLimits for the allowed number of concurrent permissible loans.Reminder: this class exists to provide email reminders to users.

These can be generic reminders with a message, or more specific reminders, which are provided by the children of this class. These child classes are relatively self explanatory.BookDue: a reminder that informs a user that a book they have out are due, including information about the loan.FeesDue: a reminder that a user has outstanding fees.MembershipRenewal: a reminder specifically for GeneralPublic library members that their membership requires renewal if they wish to continue using the library.BookAvailable: reminds a user that a copy of a book has become available.Report: a class that exists to give information to librarians.

This class has 2 child classes for specific report types.StatsOfReservation: reports to the librarian on the number of times a book has been reserved, to help them gain information on the popularity of certain books.ArchiveOfLoan: reports to the librarian on the number of times a book has been loaned, to help them gain information on the popularity of certain books.2.4 Functional workflow designThe Use Case shown in the sequence diagram below is the “Extend Loan” use case. The objects involved are UnderGradStudent, CopyOfBook and Book. The UnderGradStudent object is an instance of the class to act as the user that is requesting to extend their loan.

The sequence is initialised with the requestRenewal message. The self-referential function, getMembershipValidity, checks the validity of the users membership. If the length of the membership has greater than 30 days left, the process is continued. If it is less than or equal to 30 days, then a message is sent back to the user to say that they have insufficient membership time left, so they must renew before they can make this request.The next message is another self-referential message.

This is to check if the user has any outstanding fines that they must pay. A user is not allowed to extend a loan with an outstanding fine. If the user has an outstanding fine, they will be sent a message to alert them to this. The third message is to check the amount of renewals that the user has requested on this book. The arrow points to the class that the method exists in. The getRenewalCounter function is defined within the CopyOfBook class.

If this method returns a value less than 7, then the process is continued. If it returns a value of greater than or equal to 7, then a message is sent back to the user to alert them that they have already renewed this book the maximum number of times.The 4th message is a self-referential message in the CopyOfBook class. IsBookDue checks if the book that has been requested is due. If it is overdue then a message is sent back to the user to indicate that the book is overdue, this implies that there are now fines to pay for this, so an extension on this book is not available.The 5th message is checkReserStatus, which checks the reservation status of the book.

This method is defined within the Book class. This returns whether or not the book is reserved. If it is reserved, then a message is sent back to the user stating this and therefore an extension on this book can not be made. The 6th message is calcDueDate. This is triggered if the book has not been reserved. The new due date, after the extension, is calculated within this. This method belongs to the CopyOfBook class.

The 7th and 8th messages are self-referential, synchronous messages, belonging to the CopyOfBook class. Both of these are executed at the same time. The 7th message sets the new due date of the book, as calculated by the calcDueDate method. The 8th message then increments the renewal counter as a renewal has been completed. The renewal counter is used to check if the library member has exceeded the maximum amount of renewals at the start of the extend loan sequence. Once all of these have been completed, a confirmed message is sent back and the process has been completed.

The design decision that has been made is to check all of the parameters needed for a successful reservation first, before setting a book to be reserved. If the book was reserved before these checks then errors in the system could be made as books may not be kept track of. For a reservation to be made, the UnderGradStudent, the instance of LibraryMember in this case, must have no less than 30 days left on their membership as this means that they will need to renew their library membership. The UnderGradStudent must also have no outstanding fines for previously or currently overdue books. They also must be within the limit of renewals of the book, which is set to 7. For a reservation to be made, all of these requirements must be satisfied, hence these have been checked first and return error messages if they have not been passed.2.

5 System component designThe AccountManagement component contains all functionality related to managing a member of the library. It contains methods from the LibraryMember class such as addMember, removeMember and accessing member data such as a username or password and any reservations they have made. For this reason it is directly connected to Login/Logoff component. This component handles the logIn and logOut functions from the abstract LibraryMember class. By separating the Login/Logoff functionalities from AccountManagement, the component could be easily implemented into another user based system. The AccountManagement class is also connected to FineHandling, which is a component that will calculate any fines a library member has. It will access data from AccountManagement and calculate if a fine is required for a given member using the variables from the CopyOfBook class and functions from LibraryMember such as calulateFine() and setTotalFine(). If the library member is an InternalMember, ie an undergrad student, postgrad student or member of staff, they have access to book recommendations.

For this reason the Recommendations component was created which, as labeled, is not available to the general public. This component allows the functions getRecommended and setRecommended, handling any recommended books in the library. AccountManagement also has access to external ports, these being RISIS and HR. RISIS handles all student accounts so allows direct access for any students of the university. HR handles any queries or requests for accounts that is out of the library system’s scope. If this component was to be reused, RISIS could be replaced by an employee database for a company or any organisation that holds member credentials on external systems. HR could also be implemented in a different environment. Another major component created was BookHandling, which manages any CopyOfBook classes and is crucial to the effective functionality of any library system.

BookHandling contains data on which books a member has taken out, what they have on loan and if they have made any requests. Since access to the CopyOfBook class is required by AccountManagement, BookHandling provides an interface to it. Since the system has the capability to generate reports, a separate component was made to handle this. There are two type of report that can be generated, these being popularity reports and fine reports. By separating these functionalities into their own component, it would be possible to implement many other different types of report in a different system if required.

Since this component needs data on a member’s fines, it is directly connected to the FineHandling component. For popularity reports, the component needs to access variables such as numLoans from the StatsOfLoan class which keeps track of how many times the book has been loaned, so it has a direct connection with the BookHandling component. It is also connected to another component named CatalogueHandling which deals with the library collection as a whole. This component deals with a lot of data, for example the publishers, titles and authors of the books in the library.

The component handles the totalCopies of books and reservation statuses of them, using functionality from the Book class. Since CatalogueHandling is connected to Reports, popularity reports can be created correctly and also the library catalogue can use data from the reports to manage the books more efficiently, ordering in more popular books for example.There are two more components that are connected to BookHandling, these are the Reminders component and the SearchCatalogue component.

In the Reminders component, all data on which books are due and what fines need to be payed are contained. These come from the Reminder class which has four children classes, these being BookDue, FeesDue, MembershipRenewal and BookAvailable. All are capable of using the generateReminder() method and sending it to the respective library member using sendMessage(). This reminder component was designed to be capable of sending any messages given a set of data to any members of the system, so would be reusable in many other scenarios similar to this library system. It provides an interface to BookHandling which will access the methods provided and send the messages when needed. The SearchCatalogue component is capable of browsing through the system’s database, for this instance it’s full of Book classes.

This component has a direct connection with BookHandling so it can access the books in the library and display them to any member requesting to see them.ODBC and ErrorHandling components were added to represent open database connectivity, which is a programming interface used for accessing the database management system, and any error handling required within the system.Conclusions and recommendationsSystem analysis is “the process of studying a procedure or business in order to identify its goals and purposes and create systems and procedures that will achieve them in an efficient way. It is a problem-solving technique that breaks down a system into its component pieces for the purpose of the studying how well those component parts work and interact to accomplish their purpose.”(Bentley and Whitten, n.d.

)We successfully modeled and designed a library system that could feasibly be implemented into a working digital system. Difficulties we encountered include:Shit teammatesPoor banterNo sense of humourReferencesBennett, S., McRobb, S. and Farmer, R. (2018).

Glossary of Key Terms. online Highered.mheducation.com.

Available at: http://highered.mheducation.com/sites/0077110005/student_view0/glossary.html Accessed 16 Jan. 2018.Bentley, L. and Whitten, J. (n.

d.). Systems analysis & design for the global enterprise =.