Scribd
Upload
3 views7 pages

Oops

The Loan Approval System simulates a bank's loan approval process using C++ OOP principles, including encapsulation, inheritance, and polymorphism, while employing Strategy and Factory design patterns for flexible approval logic. It features a multi-role login system for Admin and User roles, a Customer class that ties customer profiles to approval strategies, and a Loan class that manages loan details. Additionally, it includes a credit score converter function and specific strategies for different customer types, allowing for easy expansion and modification of the approval process.

Uploaded by

ruthlessr19
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
3 views7 pages

Oops

The Loan Approval System simulates a bank's loan approval process using C++ OOP principles, including encapsulation, inheritance, and polymorphism, while employing Strategy and Factory design patterns for flexible approval logic. It features a multi-role login system for Admin and User roles, a Customer class that ties customer profiles to approval strategies, and a Loan class that manages loan details. Additionally, it includes a credit score converter function and specific strategies for different customer types, allowing for easy expansion and modification of the approval process.

Uploaded by

ruthlessr19
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 7

Slide 1: Theoretical Overview

Loan Approval System simulates a bank’s loan approval process for different customer
profiles (e.g., salaried employees, business owners, etc.).
Built using fundamental C++ OOP principles – demonstrating encapsulation (organizing
data/functions within classes), inheritance (using base & derived classes for shared
interfaces), and polymorphism (flexible behavior via base-class pointers).
Employs Strategy and Factory design patterns to handle varied approval logic. The Strategy
pattern lets the program choose different approval algorithms at runtime (one for each
customer type). The Factory pattern is used to create the appropriate strategy object, making
it easy to add new customer types without changing core logic.
Slide 3: UML Class Diagram

Slide 4: Login System


Slide 4: Login System (Admin & User Roles)
 Multi-Role Login: The login system supports two roles – Admin and User – each
with a different username/password. For simplicity, these credentials are predefined in
the code (e.g., "admin"/"admin123" for Admin, "user"/"user123" for a regular user).
 Credential Verification: When a user logs in, the program checks the input against
both the Admin and User credential sets. An if/else chain determines the role:
o If the username/password match the Admin credentials, the user is logged in
as an Admin.
o Else if they match the User credentials, the user is logged in as a User.

o If neither match, the login fails (invalid credentials).

 Role-Based Workflow: After a successful login, the system routes the user to the
appropriate workflow:
o Admin: Gains access to administrative functions (e.g. view all loan
application data, manage loans).
o User: Proceeds to the standard user flow (e.g. apply for a new loan).

 This design ensures that an Admin has a different experience (and privileges) than a
normal user once authenticated. The code below illustrates the updated login logic
with role handling:
Slide 5: Customer Class
 Customer Profile: The Customer class encapsulates loan applicant data and ties a
customer to an approval strategy. When a Customer is created, it selects an approval
strategy based on the customer’s profile type (using the factory). It also holds a Loan
instance for the requested loan details.
Slide 6: Loan Class
 Loan Details: The Loan class encapsulates information about a loan request. It stores
the loan amount and duration, and provides a method to check if the loan is overdue
(based on a simple simulation of time passing).
Comments: In this simple model, when monthsRemaining drops to 0 or below, the loan is
considered due/overdue. The payMonth() function simulates time advancing or payments
being made. (In a real system, dates and payment schedules would be used instead of a
counter.)
Slide 7: Credit Score Converter Function
 Utility Function: A standalone function is used to convert or interpret credit score
values. This can help translate a raw credit score into a category that the approval
logic might use (e.g., “Good” or “Poor” credit).

This function takes an integer credit score and returns a string category. For example, a score
of 700 would yield "Good". Such a converter could be used to adjust loan terms or approval
thresholds based on categories, but in our project the numeric score is used directly in the
strategy logic for simplicity.

Slide 7: Credit Score Converter (Income to Score Formula)


 Purpose: We added a component to convert a user’s annual income into a credit
score as part of the loan approval evaluation. Credit scores typically range from 300
(poor) to 850 (excellent)nerdwallet.com, so our converter ensures the output stays
within this range.
 Linear Scaling Formula: The conversion uses a simple linear formula to scale
income to a credit score. In essence, higher income yields a higher credit score (on
our scale). We chose a linear mapping that increases the score gradually with income:
o For example, an income of $50,000 might correspond to a credit score around
620, $100,000 to about 680, and $150,000 to roughly 740. As income rises,
the score moves upward within the 300–850 range.
o Based on these sample points, we derived a slope for the income-to-score
relationship (about 0.0012 per dollar). This means roughly each $50k increase
in income adds ~60 points to the score. (These values are for demonstration
and provide a reasonable scaling for the project.)
 Clamping to Range: The formula ensures the computed score never goes below 300
or above 850. If the raw calculation falls outside this range, it is clamped to the
nearest limit.
 The code snippet below implements the Credit Score Converter as a function, with
comments explaining the formula:

Code Explanation: The function convertIncomeToCreditScore takes a yearly income and


calculates a credit score. We use the formula score = 0.0012 * income + 560 to linearly
convert income to a score. For instance, if income = 100000, the calculation gives
0.0012*100000 + 560 = 680. We then apply bounds: if the computed score is below 300, we
set it to 300; if above 850, we cap it at 850. Finally, we return the score as an integer. The
example usage demonstrates the function with a $100k income, which yields a credit score of
about 680.
Note: This is a simplified model for educational purposes. In reality, credit scores are
determined by many factors (not just income) and calculated using complex algorithms.
However, for this project, the above linear formula provides a clear and beginner-friendly
way to simulate how a higher income could translate to a better credit score, fitting within the
standard scoring range.
Slide 9: Salaried Strategy Implementation
 Concrete Strategy (Salaried): SalariedApproval is a subclass of ApprovalStrategy
that implements the loan approval rules for salaried individuals. For example, we
might require a minimum credit score and limit the loan amount for approval. (Other
customer types like Business or SelfEmployed would have similar classes with their
own criteria.)

Comments: In this example, a salaried customer with a credit score of 650 or above
can be approved for loans up to 50,000. The check uses data from the Customer and Loan
objects. By changing the thresholds or adding more conditions, we can easily tweak the
approval policy for salaried customers. BusinessApproval and SelfEmployedApproval
classes (not shown here) would override approveLoan with different rules suitable for those
profiles.
Slide 10: Approval Strategy Factory
 Factory Pattern: The ApprovalFactory class provides a static method to create the
appropriate ApprovalStrategy object based on the customer’s profile type. This
separates the decision of which strategy to use from the rest of the code. The
Customer simply asks the factory for a strategy, without worrying about the concrete
class names.
Here, getStrategy checks the profile type and allocates the corresponding strategy
object. For example, if profileType is "Business", it returns a new BusinessApproval(). Using
a factory method centralizes object creation logicfile-jx2pu6frxwv6fncn4hdfj5, making it
easy to add new types (just extend ApprovalStrategy and update this method) without
scattering new calls throughout the code. (Note: In a full program, we would ensure to delete
the allocated strategy or use smart pointers to avoid memory leaks.)

You might also like