208 ASSIGNMENT 3
1. UML CLASS DIAGRAM
Link:https://lucid.app/lucidchart/c14e8e19-b728-4bc0-9460-a09332ff2aa4/edit?
viewport_loc=-5%2C443%2C4186%2C1888%2CHWEp-vi-
RSFO&invitationId=inv_8a7c996e-a81b-41ef-8533-f17afb4576d3
DESCRIPTION OF EACH CLASS
USER
The user class is the parent class for all users in the system. It provides common
attributes and methods for all users. The attributes of the user class are private,
and the methods are pubic.
The Attributes of the user class are:
userID – this provides an ID to the user.
name – the name attribute is the name of the user.
email – the email address of the user
password – the password of the user’s account.
role – the type of role of the user i.e. donor, volunteer, employee, etc.
The Methods of the user class allows the user to:
1. create an account.
2. Log in to their account.
3. Update their account or change their personal information.
4. Change their password.
DONOR
The donor class represents the users that make donations to support the
organization. The donor class inherits the attributes and methods of the user
class.
The Methods concerning the donor class allows the donor to:
1. Make a donation.
2. View their donation history.
3. Generate receipts of their donation.
VOLUNTEER
The volunteer class represents the users that wish to participate in volunteer
activities. The volunteer class also inherits the user class.
The Methods of the volunteer class allows the user or volunteer to:
1. Browse or search for volunteer opportunities.
2. Register for volunteer opportunities.
EMPLOYEE
The employee class represents the users who manage the organization’s
activities and events or people employed by the organization to manage their
activities and events. The employee class also inherits the attributes of the user
class.
The Methods of the employee class allows the employees to:
1. Create an event.
2. Manage an event e.g. update event details and track registrations.
3. Communicate with the volunteers e.g. send notifications to volunteers.
4. Generate reports e.g. generate reports on volunteer activities.
BENEFICIARY
The beneficiary class refers to users who receive help or support from the
organization. This class also inherits the attributes of the user class.
The Methods of the beneficiary class allows the user or beneficiary to:
1. Apply for support or aid.
2. View available aid programs.
DONATION
The donation class refers to donations made by a donor to the organization. The
donation class is related to the donor class by association.
The Attributes of the donation class are:
donationID – this provides an ID for every donation.
Amount – the amount of the donation.
Date – the date the donation was made.
donorID – this provides the ID of the donor.
The Methods of the donation class allows the system to:
1. Process the donation.
2. Retrieve the details of the donation.
OPPORTUNITY
The opportunity class represents the available volunteer opportunities.
The attributes of the opportunity class are:
opportunityID – this provides an ID for the opportunity.
Title – this is the title of the opportunity.
Description – the description of the opportunity.
Date – the date of the opportunity.
Locati0on – the location of the opportunity.
The Methods of the opportunity class allows the system to:
1. Retrieve available opportunities.
2. Register a volunteer for the opportunity.
EVENT
The event class represents events organized by the employees of the
organization for volunteer activities.
The attributes of the event class are:
eventID – this provides an ID for an event.
Title – the title of the event.
Description – the description of the event.
Date – the date of the event.
Location – location of the event.
employeeID – this provides the employee who created the event.
The Methods of the event class are:
1. create a new event.
2. Update the information for an existing event.
3. Keep track of all event registrations.
4. Send event-related notifications.
APPLICATION
The application class represents an application submitted by a beneficiary for aid
or support.
The attributes of the application class are:
applicationID – the ID of an application.
beneficiaryID – the ID of the beneficiary who submitted the application.
programID – the ID of the program the application is for.
Status – the status of the application.
Date – the date of the application
The Methods of the application class are:
1. Submit an application
2. Get the status of the application.
PROGRAM
The program class represents the support programs available for beneficiary
users.
The attributes of the program class are:
programID – the ID for the program.
Name – the name of the program.
Description – the description of the program.
EligibilityCriteria – the eligibility requirements for the program.
There is only method for the program class:
1. Get or retrieve program details.
NOTIFICATION
The notification class represents notification sent to users.
The attributes of the notification class are:
1. notificationID – the ID of the notification.
2. recipientID – the ID of the recipient of the notification/
3. message – the content of the notification.
4. dateSent – the sent date of the notification.
There is only one method in the notification class:
1. Send all notifications.
REPORT
The report class refers to reports generated by employees for analysis. The
report class is related to employee class by association
The attributes of the report class are:
reportID – the ID of the report.
Type – the type of report e.g. donation report etc.
Data – the data included in the report.
generationDate – the date the report was generated.
The Methods of the report class are:
1. generate the report.
2. Visualise the data in the report.
2. HIGH LEVEL ARCHITECTURAL DIAGRAM
The above is a high-level architectural diagram for the system. The diagram
shows the major components and their interactions. The components are the
client (user interface), Internet, web server, front-end and back-end services, and
a database.
THE COMPONENTS AND THEIR ROLES
1. Client - End-users connect with the system using devices such as PCs,
laptops, tablets, and smartphones.
2. Internet - The medium over which clients and web servers communicate.
3. Web server - Role: Receives incoming client requests, processes them, and
responds.
4. Front-end components – Build user interface components.
5. Back-end components – Handle core functionalities and business logic.
6. Data Storage – Manages the storage and retrieval of data.
THE INTERACTION BETWEEN THE COMPONENTS
1. Client Interaction - Users send HTTP requests to the web server and
receive responses.
2. Request Processing - Web server routes requests to backend services for
processing.
3. Data Storage - Backend services read/write data from/to the database.
4. Response Handling - Web server sends processed responses back to the
client.
3. UML SEQUENCE DIAGRAM
The above is a uml sequence diagram for a user registration process.
The Actors in the user registration process above are:
1. User – the person who wishes to create or register an account.
2. User Interface – the front-end interface with which users interact.
3. Core Services – the back-end service that manages the registration logic.
4. Data Storage – a database that stores user information.
5. Notification Service – the service that sends notifications or a confirmation
email to the user.
The sequence of interactions in the process are:
1. The User completes the registration form and submits it using the User
Interface (UI).
2. The UI delivers the registration information to Core Services.
3. The Core Services validate the registration information.
4. If the validation is successful, the Core Services store the user information
in the Data Storage.
5. The Core Services then request that the Notification Service send a
confirmation email to the user.
6. The Notification Service sends the confirmation email.
7. The Core Services responds to the UI with a registration success message.
8. The UI shows the User the success message.
9. If the validation fails, the Core Services respond to the UI with a
registration failure message.
10.The UI displays the error message to the user.
4. ENTITY RELATIONSHIP DIAGRAM
Link:https://lucid.app/lucidchart/c14e8e19-b728-4bc0-9460-a09332ff2aa4/edit?
viewport_loc=-1798%2C-
554%2C4517%2C1882%2Ci~tPCUvc0h1g&invitationId=inv_8a7c996e-a81b-
41ef-8533-f17afb4576d3
The above is an entity relationship diagram for the project.
The entities in the diagram above are:
1. User – it represents the system’s users, which include donors, volunteers,
employees, etc. Stores information about all users in the system
2. Donation – it represents user donations. Keeps track of all user donations,
which are linked to the users who made them.
3. VolunteerOptunities – it indicates the volunteering options available to
volunteers.
4. Event – it represents the events organized by the employees. It also
contains information about the events organized by the employees.
5. Notification – refers to notifications delivered or sent to users, such as
confirmation emails.
The attributes of the user entity are:
1. User_id – this is the primary key (int)
2. Username (string)
3. Email (string)
4. Password (string)
5. Role – example donor, employee, etc. (string)
The attributes of the donation entity are:
1. Donation_id – this is the primary key (int)
2. User_id – a foreign key to user entity (int)
3. Amount (float)
4. Date (date)
The attributes of the volunteerOpportunity entity are:
1. Opportunity_id – this is the primary key (int)
2. Title (string)
3. Description (string)
4. Location (string)
5. Date (date)
The attributes of the event entity are:
1. Event_id – this the primary key (int)
2. Title (string)
3. Description (string)
4. Location (string)
5. Date (date)
The attributes of the notification entity are:
1. Notification_id – this is the primary key (int)
2. User_id – a foreign key to user entity (int)
3. Message (string)
4. Date_sent (date)
The relationships between the entities are:
1. A user can make zero or many donations.
2. A particular donation can have one and only one donor or user.
3. A user can receive zero or many notifications.
4. A particular notification can be sent to one and only one user.
5. A user can register for zero or many volunteer opportunities.
6. A volunteer opportunity can have many users registered.
7. A volunteer opportunity belongs to one event.
8. An event can have many volunteer opportunities.
NB: I used lucid chart to draw diagrams 1, 2, and 4 and used draw.io to
draw diagram 3.
