unit 20 advanced programming

<span class="text_page_counter">Trang 1</span><div class="page_container" data-page="1">

<b> ASSIGNMENT 2 </b>

</div><span class="text_page_counter">Trang 3</span><div class="page_container" data-page="3">

<b>❒ Summative Feedback: Resubmission Feedback:</b>❒<b>❒ </b>

<b>Lecturer Signature:</b>

</div><span class="text_page_counter">Trang 5</span><div class="page_container" data-page="5">

<b>II. Meaning of using UML ... 10 </b>

<b>III. A short description about the scenario of the application. Describe which classes, interfaces, … that you use for your application. ... 10 </b>

<b>IV. Class Diagram of your application. ... 11 </b>

<b>V. Give an analysis on how the scenario will be solved (analyze classes, interfaces, relationships, …). Give the reasons why you use abstract, interfaces, encapsulation, … in your classes ... 13 </b>

<b>VI. Implement code for your application with OOP in C#. (capture all source code and result when run application). Explain the source code ... 14 </b>

<b>B. Discuss a range of design patterns with relevant examples of creational, structural and behavioral pattern types (P4) ... 43 </b>

<b>I. Define Design Patterns... 43 </b>

<b>II. In each main type of DP: ... 47 </b>

Conclusion ... 75

References ... 76

</div><span class="text_page_counter">Trang 7</span><div class="page_container" data-page="7">

Figure 6. Class diagram of librarian management system ... 12

Figure 7. Class Person ... 15

Figure 8. Verify() method in Class User ... 15

Figure 9. CheckAccount() method in Class User ... 16

Figure 10. GetBookInfo() method ... 16

Figure 11. BorrowBooks method ... 17

Figure 12. ReturnBooks method ... 18

Figure 13. DisplayBorrowedBooks() method ... 19

Figure 14. DisplayBookList method ... 19

Figure 15. Class Librarian ... 20

Figure 16. Verify method in Librarian Class ... 20

Figure 17. CheckAccount method in Librarian Class ... 20

Figure 18. GetBookInfo in Librarian Class ... 20

Figure 19. Search method in Librarian Class ... 21

Figure 20. ProcessBorrowRequest method in Librarian Class ... 21

Figure 21. DisplayIssues method in Librarian Class ... 21

Figure 22. DisplayLibrarians method in Librarian Class ... 22

Figure 23. DisplayUsers method in Librarian Class ... 22

Figure 24. ProcessUserRequests method in Librarian Class ... 23

Figure 25. ProcessApprovedRequest method in Librarian Class ... 24

Figure 26. ProcessDeniedRequest method in Librarian Class ... 24

Figure 27. DisplayRequests method in Librarian Class ... 25

Figure 28. ManageBooks method in Librarian Class (1) ... 25

</div><span class="text_page_counter">Trang 8</span><div class="page_container" data-page="8">

Figure 29. ManageBooks method in Librarian Class (2) ... 26

Figure 30. ManageBooks method in Librarian Class (3) ... 26

Figure 31. ManageBooks method in Librarian Class (4) ... 26

Figure 32. ManageBooks method in Librarian Class (5) ... 27

Figure 33. ManageBooks method in Librarian Class (6) ... 27

Figure 34. ProcessIssues method in Librarian Class (1) ... 27

Figure 35. ProcessIssues method in Librarian Class (2) ... 28

Figure 36. ProcessIssues method in Librarian Class (3) ... 28

Figure 37. Class Account ... 29

Figure 38. Class Book ... 29

Figure 39. Class IssueDetail and Issue (1) ... 30

Figure 40. Class IssueDetail and Issue (2) ... 30

</div><span class="text_page_counter">Trang 9</span><div class="page_container" data-page="9">

Figure 41. Class Program (1) ... 30

Figure 42. Class Program (2) ... 31

Figure 43. SelectRole Method... 32

Figure 44. LoginUser method... 32

Figure 45. LoginLibrarian method ... 32

Figure 46. WelcomeUser method ... 32

Figure 47. WelcomeLibrarian method ... 33

Figure 48. UserInteraction method ... 33

Figure 49. LibrarianInteraction method ... 34

Figure 50. GenerateBooks method ... 35

Figure 51. GenerateUsers method ... 35

Figure 52. GenerateLibrarians method ... 35

Figure 53. Output of the source code Role section ... 36

Figure 54. Output of the source code User Login ... 36

Figure 55. Verify their identity, Check their account details, View information ... 36

Figure 56. Menu of user ... 37

Figure 57. Request to borrow books ... 37

Figure 58. Request to borrow books (1) ... 37

Figure 59. Return borrowed books ... 37

Figure 60. Return borrowed books (1) ... 38

Figure 61. See the list of books being borrowed ... 38

Figure 62. Exit the user session ... 38

Figure 63. Output of the source code Librarian Login ... 38

Figure 64. Verify their identity ... 38

Figure 65. Menu of librarian ... 39

Figure 66. View list of all librarians ... 39

Figure 67. View list of all users and the books they are borrowing ... 40

Figure 68. Manage the library's collection of books ... 40

Figure 69. Manage the library's collection of books (1) ... 41

Figure 70. Manage the library's collection of books (2) ... 41

</div><span class="text_page_counter">Trang 10</span><div class="page_container" data-page="10">

Figure 71. Manage the library's collection of books (3) ... 41

Figure 72. Manage the library's collection of books (4) ... 42

Figure 73. Manage the library's collection of books (5) ... 42

Figure 74. Manage the library's collection of books (6) ... 42

Figure 75. Process book borrowing and returning requests ... 43

Figure 76. Exit the librarian session ... 43

Figure 77. Class diagram of Singleton pattern ... 49

Figure 78. Class diagram of Factory Pattern ... 52

Figure 79. The Source Code of Creational Design Pattern : IFactory Interface (Product) ... 53

Figure 80. The Source Code of Creational Design Pattern: Scooter and Bike classes (Concrete Products) ... 53

Figure 81. The Source Code of Creational Design Pattern: VehicleFactory Abstract Class (Creator) ... 54

</div><span class="text_page_counter">Trang 11</span><div class="page_container" data-page="11">

Figure 82. The Source Code of Creational Design Pattern: ConcreteVehicleFactory class (Concrete Creator) ... 54

Figure 83. The Source Code of Creational Design Pattern: Program Class (Client) ... 55

Figure 84. Output The Source Code of the Creational Design Pattern ... 55

Figure 85. Class diagram of Structural Pattern Composite ... 58

Figure 86. Class diagram of Adapter Pattern ... 61

Figure 87. The Source Code of Structural Design Pattern: Interface IEmployed (Component) ... 62

Figure 88. The Source Code of Structural Design Pattern: The Employee class (Composite) ... 62

Figure 89. The Source Code of Structural Design Pattern: The Contractor class (Leaf) ... 63

Figure 90. The Source Code of Structural Design Pattern: Inside Program class (Client) ... 63

Figure 91. Output The Source Code of the Structural Design Pattern ... 64

Figure 92. Class diagram of Observer Pattern ... 66

Figure 93. Class diagram of Command Pattern ... 70

Figure 94. Abstract Class: Stock ... 72

Figure 95. Interface: Investor ... 73

Figure 96. Concrete Class: ConcreteInvestor ... 73

Figure 97. Concrete Classes: Microsoft and Reliance ... 74

Figure 98. Main Program: Program ... 75

Figure 99. Output The Source Code of the Behavioral Design Pattern ... 75

<b>List of Tables </b>Table 1. Detailed description of the class diagram ... 12

Table 2. Creational Design Patterns ... 44

Table 3. Structural Design Patterns ... 45

Table 4. Behavioral Design Patterns ... 46

</div><span class="text_page_counter">Trang 13</span><div class="page_container" data-page="13">

<b>Introduction </b>

This report outlines the development of a comprehensive library management system (LMS) utilizing UML class diagrams and practical design pattern implementations. UML serves as a visual tool for modeling system structure and relationships, while C# programming language underpins the LMS implementation. Design patterns, such as Observer and Strategy, are employed to address specific challenges like state changes and payment strategies. This report offers a practical guide for crafting robust and efficient LMS solutions to enhance library services and user experience.

<b>Class Notation </b>

A class notation consists of three parts:

<b>- Class Name: </b>

</div><span class="text_page_counter">Trang 14</span><div class="page_container" data-page="14">

o The name of the class appears in the first partition.

<b>- Class Attributes: </b>

o Attributes are shown in the second partition. o The attribute type is shown after the colon.

o Attributes map onto member variables (data members) in code.

<b>- Class Operations (Methods): </b>

o Operations are shown in the third partition. They are services the class provides.

</div><span class="text_page_counter">Trang 15</span><div class="page_container" data-page="15">

o The return type of a method is shown after the colon at the end of the method signature.

o The return type of method parameters is shown after the colon following the parameter name.

o Operations map onto class methods in code

<b>Class Relationships </b>

<b>- Inheritance (or Generalization): </b>

Figure 1. Inheritance o Represents an "is-a" relationship. o An abstract class name is shown in italics.

</div><span class="text_page_counter">Trang 16</span><div class="page_container" data-page="16">

o SubClass1 and SubClass2 are specializations of Super Class.

o A solid line with a hollow arrowhead that point from the child to the parent class

<b>- Simple Association: </b>

Figure 2. Simple Association o A structural link between two peer classes.

</div><span class="text_page_counter">Trang 17</span><div class="page_container" data-page="17">

o There is an association between Class1 and Class2 o A solid line connecting two classes

<b>- Aggregation: </b>

Figure 3. Aggregation o Class2 is part of Class1.

o Many instances (denoted by the *) of Class2 can be associated with Class1. o Objects of Class1 and Class2 have separate lifetimes.

o A solid line with an unfilled diamond at the association end connected to the class of composite

<b>- Composition: </b>

Figure 4. Composition o Objects of Class2 live and die with Class1. o Class2 cannot stand by itself.

o A solid line with a filled diamond at the association connected to the class of

</div><span class="text_page_counter">Trang 19</span><div class="page_container" data-page="19">

o Class1 depends on Class2 o A dashed line with an open arrow

<b>II. Meaning of using UML </b>

There are many benefits to using UML. Some of these include:

<b>- Improved communication: UML diagrams may facilitate better communication </b>

between developers, testers, and project managers, among other stakeholders in

<b>software development projects. </b>

<b>- Reduced errors: Because UML diagrams may spot possible issues early in the design phase, they can assist decrease mistakes in software development. - Increased maintainability: UML diagrams, which provide a clear and brief </b>

summary of the structure and interactions inside the system, may aid in improving

<b>the maintainability of software systems. </b>

<b>III. A short description about the scenario of the application. Describe which classes, interfaces, … that you use for your application. </b>

The scenario of the application is a library management system. The system will allow users to borrow, return, and renew books. The system will also allow librarians to manage the library's collection of books and users.

<b>Classes and their attributes/methods: </b>

<b>- Person: This is a base class with attributes such as name and id. It also includes </b>

methods like verify(), CheckAccount(), and get_book_info().

<b>- User: This class inherits from the Person class. It shares the same attributes and </b>

</div><span class="text_page_counter">Trang 20</span><div class="page_container" data-page="20">

methods as the Person and represents a user of the library.

<b>- Account: This class has attributes that track borrowed, returned, reserved, and </b>

lost books. It also keeps track of fine amounts. Its method calculate_fine() seems to be for calculating the fine for overdue books.

<b>- Issue: This class represents a book issue event and holds the IDs of both the </b>

librarian and the user involved, along with the respective methods to manipulate the book issuing record.

</div><span class="text_page_counter">Trang 21</span><div class="page_container" data-page="21">

<b>- Librarian: This class also inherits from the Person class and includes additional </b>

attributes such as a Password. It also includes methods specific to librarian function, like verify_librarian() and sreach() (likely meant to be search()).

<b>- Book: This class represents a book in the library and contains attributes like title, </b>

id, author, isbn, and publication. The methods related to this class pertain to showing due date, checking reservation status, providing feedback, requesting books, and renewing book information.

<b>- Issue Detail: This class represents the details of a book issue. It might contain information about the issue, like who issued it and when it was issued. </b>

<b>- Return: This class likely represents the occurrence of a book being returned to the </b>

library. Just like the "Issue" class, it would contain links to a specific user and possibly to a librarian, indicating who is handling the return. It may contain methods to manage return transactions, like updating the user's account regarding the status of the returned book.

<b>- ReturnDetail: This class would probably capture more specific details about the </b>

book returned, such as book ID, the date/time of the return, any fines paid during the return process due to late return, damage, or loss, the condition of the book

<b>upon return, etc. </b>

From these classes and their interactions, it appears that this application is intended to manage interactions between users and librarians in a library setting, revolving around the issuance, return, and reservation of books. The User, Librarian, and Book classes all inherit

</div><span class="text_page_counter">Trang 22</span><div class="page_container" data-page="22">

, , , ,

from the Person class, indicating that users and librarians have some common attributes and behaviors. Meanwhile, the Account class seems to manage users' interactions with books, and the Issue and Issue Detail classes manage specific instances of books being issued.

<b>IV. Class Diagram of your application. </b>

</div><span class="text_page_counter">Trang 23</span><div class="page_container" data-page="23">

Figure 6. Class diagram of librarian management system

There are 10 (Interface, Person, Issue detail, Book, Account, …) classes linked together to create a complete system:

Table 1. Detailed description of the class diagram

</div><span class="text_page_counter">Trang 24</span><div class="page_container" data-page="24">

<b>Type Name Description Relationship </b>

Represents the library system's user interface, where users and librarians interact with the system. This is where the classes and objects come into play in real-world scenarios.

Interacts with all the other classes via initiating object methods and displaying results.

</div><span class="text_page_counter">Trang 25</span><div class="page_container" data-page="25">

<b>Class Person </b> ^{Represents a generic persona in the library}

system with attributes like name, id.

Parent to User and Librarian classes.

borrowed, reserved, returned, and lost books.

Associated with the User class.

attributes like title, author, and ISBN.

Associated with IssueDetail, ReturnDetail.

user.

Associations with User, Librarian and IssueDetail.

were issued, due date, etc.

Child of Issue, associated with Book.

a borrowed book to the library.

Association with User, Librarian, and ReturnDetail.

<b>l </b>

Captures more specific details about the book returned including Return date, any fine paid, etc.

Child of Return, associated with Book.

<b>V. Give an analysis on how the scenario will be solved (analyze classes, interfaces, relationships, …) Give the reasons why you use abstract, interfaces, encapsulation, … in . </b>

</div><span class="text_page_counter">Trang 27</span><div class="page_container" data-page="27">

- The Book class would then update its attributes and reflect the changes induced by the Issue process.

- If a User decides to return a book, a Return object would be created, which would then associate with the ReturnDetail class to store specifics about the returned Book.

- The Account associated with the User would update its records based on the Issue or Return processes.

The Role of Librarian can be to supervise these processes, validate Issue or Return actions, etc., based on the requirements of the real-world scenario.

The reasons for using inheritance, interfaces, and encapsulation were integral in solving our problem:

- Inheritance allowed for code reusability and logical consistency. This is evident from User and Librarian classes inheriting from Person, which reduces the duplication of code and makes our system easier to manage and expand. - Interfaces provide standardized behavior that multiple classes can use. Here, if a

class interacts with the Interface, then we can be sure that it implements the required methods, providing flexibility and promoting a strong system design. - Encapsulation contributes to making an object's state modification-safe and

grants control on how the end-users can use the objects of our classes. Our classes like Issue, Return, Book encapsulate their specific details and operations,

</div><span class="text_page_counter">Trang 28</span><div class="page_container" data-page="28">

making the system design robust and secure.

Therefore, carefully employing these object-oriented principles makes the system more manageable, scalable, and robust, catering to complex scenarios efficiently.

<b>VI. Implement code for your application with OOP in C#. (capture all source code and result when run application). Explain the source code </b>

<b>1. Class Person </b>

</div><span class="text_page_counter">Trang 29</span><div class="page_container" data-page="29">

This is an abstract class that serves as a base for the User and Librarian classes. It includes properties like Name and Id, and abstract methods like Verify(), CheckAccount(), and GetBookInfo().

Figure 7. Class Person

<b>2. Class User </b>

This class inherits from the Person class and represents a user in the library system. It includes methods for verifying the user, checking the user's account, getting book information, borrowing books, and returning books.

<b>a. Verify(): </b>

This method is used to verify the user. It's an overridden method from the Person class, which means it provides a specific implementation for the User class. It simply prints a message indicating that the user has been verified.

</div><span class="text_page_counter">Trang 30</span><div class="page_container" data-page="30">

Figure 8. Verify() method in Class User

<b>b. CheckAccount(): </b>

This method checks the user's account details. It prints the user's name, the number of borrowed books, and the number of reserved books. It's also an overridden method from the Person class.

</div>