The Source Code of Creational Design Pattern: Scooter and Bike classes Concrete Products .... The Source Code of Creational Design Pattern: VehicleFactory Abstract Class Creator ..... Th
Build an application derived from UML class diagrams (P3)
Introduce UML
A UML class diagram is a kind of diagram that models a system's or application's classes, properties, actions, and connections to display the structure of the system or application Unified Modeling Language, or UML, is a common language used to describe object-oriented systems Class diagrams are used to model the classes in a software system and the relationships between them Classes are blueprints for creating objects Objects are instances of classes (Nishadha, 2022)
A class notation consists of three parts:
- Class Name: o The name of the class appears in the first partition
- Class Attributes: 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
- Class Operations (Methods): o Operations are shown in the third partition They are services the class provides 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
Figure 1 Inheritance o Represents an "is-a" relationship o An abstract class name is shown in italics 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
Figure 2 Simple Association o A structural link between two peer classes o There is an association between Class1 and Class2 o A solid line connecting two classes
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
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 composite
Dependency is a relationship between two classes where changes in one class's definition may necessitate modifications in the other This dependency is depicted by a dashed line with an open arrow, indicating that Class1 depends on Class2.
Meaning of using UML
There are many benefits to using UML Some of these include:
- Improved communication: UML diagrams may facilitate better communication between developers, testers, and project managers, among other stakeholders in software development projects
- 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 summary of the structure and interactions inside the system, may aid in improving the maintainability of software systems.
A short description about the scenario of the application Describe which classes, interfaces, … that
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
Classes and their attributes/methods:
- Person: This is a base class with attributes such as name and id It also includes methods like verify(), CheckAccount(), and get_book_info()
- User: This class inherits from the Person class It shares the same attributes and methods as the Person and represents a user of the library
- Account: This class has attributes that track borrowed, returned, reserved, and lost books It also keeps track of fine amounts Its method calculate_fine() seems to be for calculating the fine for overdue books
The BookIssue class serves as a digital record of book issuance, capturing the unique identifiers of both the librarian handling the transaction and the patron borrowing the book It provides a set of functionalities to manage the issuance process, enabling efficient tracking and maintenance of book circulation This class ensures accurate and timely updates to the book issuance database, facilitating seamless book lending and management within the library system.
- Librarian: This class also inherits from the Person class and includes additional attributes such as a Password It also includes methods specific to librarian function, like verify_librarian() and sreach() (likely meant to be search())
- Book: This class represents a book in the library and contains attributes like title, 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
- 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
- Return: This class likely represents the occurrence of a book being returned to the 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
- ReturnDetail: This class would probably capture more specific details about the 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 upon return, etc
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
, , , , 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.
Class Diagram of your application
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
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
Class Person Represents a generic persona in the library system with attributes like name, id
Parent to User and Librarian classes
Class Account Represents a user's library account tracking borrowed, reserved, returned, and lost books
Associated with the User class
Class User Inherits from Person, representing a library patron or user
Child of Person, associated with Account, Issue
Class Librarian Inherits from Person, representing a library staff member
Child of Person, associated with Issue
Class Book Represents a physical book in the library with attributes like title, author, and ISBN
Class Issue Represents the action of issuing a book to a user
Associations with User, Librarian and IssueDetail
Class IssueDetail Contains detailed info about which book(s) were issued, due date, etc
Child of Issue, associated with Book
Class Return Represents the event wherein a user returns a borrowed book to the library
Association with User, Librarian, and ReturnDetail
Captures more specific details about the book returned including Return date, any fine paid, etc
Child of Return, associated with Book.
Give an analysis on how the scenario will be solved (analyze classes, interfaces, relationships, …) Give
relationships, …) Give the reasons why you use abstract, interfaces, encapsulation, … in your classes
User or Librarian would interact with the system through the Interface This is where the system starts processing the requests
- Depending on the task, if a User decides to issue a book, it would create an Issue object invoking the CRUD methods defined in the Interface
- The Issue class would associate with the IssueDetail class to store detailed information about the issued Book
- 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 define common behaviors that various classes can adopt By adhering to an interface, a class guarantees the implementation of necessary methods This standardized approach ensures compatibility, flexibility, and promotes a robust system design By leveraging interfaces, developers can establish a clear contract between classes, enhancing the overall maintainability and extensibility of the software application.
- 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, 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.
Implement code for your application with OOP in C# (capture all source code and result when run application) Explain the source code
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(),
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 a Verify():
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
Figure 8 Verify() method in Class User b CheckAccount():
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
A creational pattern called the Factory Method Design Pattern gives subclasses the authority to choose which class to instantiate while still providing an interface for doing so It's a pattern that encourages code reuse and loose connectivity between classes (Ghergu, 2023)
- The Meaning of Design Patterns
In object-oriented programming, the Factory Method pattern is a design pattern that is part of the creational pattern group The primary objective of the Factory Method pattern is to provide an interface for object creation, while enabling subclasses to modify the kind of objects that are generated It increases the extensibility of the system and lessens the reliance between the client and certain classes (Ghergu, 2023)
Some key meanings of the Factory Method pattern include: o Providing Interface Compatibility: The Factory Method pattern makes sure that every subclass inherits from a base class or implements a common interface As a result, the client may communicate with objects via a common interface without being aware of the particulars of the class that is being used o Object Creation Process Segregation: The Factory Method pattern detaches the client from the object creation process, enabling the client to work with objects without worrying about their creation process o Reducing Dependency: By removing the client's reliance on certain classes, the Factory Method design makes it possible to easily modify or extend the system without having an impact on the client o Supporting Polymorphism: Subclasses are free to implement the object generation procedure in their own unique ways thanks to the Factory procedure pattern o Extension Ease: Creating new objects by adding new subclasses is simple and has no effect on other system components
- Using cases of this Design Patterns
This The Factory Method design pattern steps in when you want a superclass to handle creating objects, but you're open to letting subclasses tweak the types of created objects This pattern shines when you're not sure about the exact types and dependencies your code will be dealing with Check out these everyday situations where the Factory Method pattern comes to the rescue: o Cross-Platform UI Development: Crafting UI elements for an app that plays nice across various platforms The Factory Method helps generate platform- specific UI elements, like buttons, without getting your code tangled up with specific UI classes o Logistics Management System: In a logistics app, where different transportation types (trucks, ships) are handled by various subclasses The Factory Method welcomes new transportation types without shaking up the existing code o Plug-in Systems: For apps embracing plug-ins or extensions, the Factory
Method crafts instances of different plug-ins Each plug-in dances to its own tune, and the client code doesn't need to know the nitty-gritty details o Document Generation: In systems spitting out different document types (PDF,
Design patterns offer significant advantages in software development The Factory Method streamlines document creation by empowering subclasses to implement unique behaviors without compromising document integrity Resource management is enhanced by optimizing resource usage, particularly for resource-intensive objects, through the reuse of existing instances In game development, the Factory Method facilitates the creation of diverse game entities and characters.
Factory Methods excel in creating specialized objects for specific use cases For instance, in UI frameworks, they produce UI elements with platform-specific styles and behaviors, ensuring seamless integration and optimal user experience.
Subclasses can tweak the factory method to churn out platform-specific UI elements
- Benefits of UML in Factory Pattern o Improved Communication: Because UML diagrams provide a standardized way to describe the factory method design pattern, they may aid in improving communication between developers o Easier Understanding: Because UML diagrams provide the factory method design pattern in a graphical format, they may aid developers in understanding the pattern o Easier Documentation: The factory method design pattern may be documented using UML diagrams, which can facilitate future developers' comprehension of the pattern
- Class diagram Factory Pattern of
Figure 78 Class diagram of Factory Pattern
- Explanation Class diagram o IFactory: An interface that declares the Drive() method o Scooter and Bike: Classes that implement the IFactory interface and, consequently, the Drive() method These classes are the concrete products in the Factory Method pattern o VehicleFactory: An abstract class that declares the GetVehicle() method, which is supposed to return an instance of the IFactory interface either a — Scooter or a Bike o ConcreteVehicleFactory: Implements the VehicleFactory and provides the implementation of the GetVehicle() method, which returns an IFactory instance c The Source Code of Creational Design Pattern (Factory Method)
- IFactory Interface (Product): This is the common interface for the "products", defining the method 'Drive()' that takes miles as a parameter All classes implementing this interface must also define this method
Figure 79 The Source Code of Creational Design Pattern : IFactory Interface (Product)
- Scooter and Bike classes (Concrete Products): These classes implement IFactory and provide a concrete implementation of the Drive method For example, the Scooter class writes a message to the console stating the distance the scooter has driven
Figure 80 The Source Code of Creational Design Pattern: Scooter and Bike classes (Concrete Products)
- VehicleFactory Abstract Class (Creator): This declares the GetVehicle method, which when given a string, will return a product implementing IFactory However, it doesn't specify the product
Figure 81 The Source Code of Creational Design Pattern: VehicleFactory Abstract Class (Creator)
- ConcreteVehicleFactory class (Concrete Creator): This class overrides GetVehicle method from VehicleFactory Depending on the input string, it either returns a new Scooter or a new Bike, or throws an exception when it's not able to create an object for a given vehicle type
Figure 82 The Source Code of Creational Design Pattern: ConcreteVehicleFactory class (Concrete Creator)