Peer Mentoring System Architecture/Design Document

This document presents a description of the architecture and design of a Peer Mentoring System, being developed for AIH. The proposed Peer Mentoring System will help facilitate a technology-driven mentoring system within the institution.

Peer Mentoring System
Architecture/Design Document

Abstract
Mentorship is a critical component of human development. In institutions of higher
learning, mentorship is critical to help students deal with social, professional and
academic challenges. For that reason, AIH seeks to develop an online mentorship system,
which allows mentors to easily interact with students on a wide range of issues.
This document presents a description of the architecture and design of a Peer Mentoring
System, being developed for AIH. The proposed Peer Mentoring System will help will
facilitate a technology-driven mentoring system within the institution. Traditionally,
mentoring has been on a face-to-face basis. However, with the technological
advancements, and the uptake of IT in every facet of human life, there is need to have an
online system that can facilitate the mentoring program. The system will have three key
group of users; the administrators, the mentors and the students. The admins will be
responsible for allocating mentors to the students. The Mentors performs the support and
mentoring to the students, while the students will be there to be mentored.
The main objective of the proposed Peer monitoring System is to help students with,
personal development, academic performance, reflection and Career Growth. The system
will form a platform where the mentors can easily interact and support students on a wide
range of areas that the students may be seeking help or mentorship on. The major
stakeholders are the students, mentors, admin, system developer and the project manager.
In a bid to effectively analyses and present the architecture and design of the proposed
Peer Mentoring System, four different perspectives are used in describing the
architecture. The four perspective includes; the Logical View, the Process View, the
Development View and the Use Case View.
The design goal of this architectural design is usability; of the system supersedes any
other requirement. As such, the priority of the design is how usable the system is more
important than re-usability of components. The end goal is to have a system that is
efficient and easy to use; concern of how the code is organized is of low priority.
Therefore, the design priorities for the Peer Mentoring System are:
 The design should result in a simple to use and efficient system
 The design should factor in data privacy and system usability at its core.
The design should minimize complexity and enhance maintainability.

Table of Contents
1 INTRODUCTION.............................................................................................4
2 DESIGN GOALS.............................................................................................5
2.1 Background and Solutions Summary...................................................................5
3 SYSTEM BEHAVIOR......................................................................................6
3.1 Functional and Non-Functional Requirements....................................................8
4 LOGICAL VIEW..............................................................................................8
4.1 High-Level Design (Architecture).........................................................................8
4.2 Mid-Level Design..................................................................................................11
4.3 Detailed Class Design...........................................................................................14
5 PROCESS VIEW...........................................................................................15
6 DEVELOPMENT VIEW.................................................................................16
7 PHYSICAL VIEW..........................................................................................17
8 USE CASE VIEW..........................................................................................18
References............................................................................................................20

1 Introduction
This document presents a description of the architecture and design of a Peer Mentoring
System, being developed for AIH. The proposed Peer Mentoring System will help will
facilitate a technology-driven mentoring system within the institution. Like in any other
institution, AIH seeks to be considerate of issues affecting its members; particularly the
students. As such, a mentoring program - where members of faculty, staff and alumni
mentor new and continuing students, is critical for the institution. Traditionally,
mentoring has been on a face-to-face basis. However, with the technological
advancements, and the uptake of IT in every facet of human life, there is need to have an
online system that can facilitate the mentoring program.
For this scenario, the system will have three main group of users; the administrators, the
mentors and the students. The admins will be responsible for allocating mentors to the
students. The Mentors performs the support and mentoring to the students, while the
students will be there to be mentored.
The main objective of the proposed Peer monitoring System is to help students with,
personal development, academic performance, reflection and Career Growth. The system
will form a platform where the mentors can easily interact and support students on a wide
range of areas that the students may be seeking help or mentorship on.
This document aims to describe the architecture and design of the Peer Mentoring System
in a way that addresses the interest and concerns of all the major stakeholders. For the
proposed system, the major stakeholders are;
 Students: the students who seek mentorship want an architecture that provides
easy to use system functionalities and has desirable non-functional quality
features such as privacy protection, usability and reliability.
 Mentors: (Staff, Lecturers, Alumni) similar to the expectations and requirements
of the students, this stakeholder want a system whose architecture provides
functionalities in an easy to use manner and provides assurance of reliability,
usability and privacy concerns.
 Admin: the administrator stakeholder wants an architecture that provides all the
desired features and is highly stable and reliable.
 System Developers: since the task of implementing the design falls on the hands
of the developers/programmers, they want an architectural design that reduces
implementation complexity and requires less effort to implement.
 Project Manager: tasked with the role managing the project that will implement
the proposed system; the manager want an architecture that can be sub-divided; in
order to ease the process of managing the deliverables of the project and the
resources.
In a bid to effectively analyse and present the architecture and design of the proposed
Peer Mentoring System, four different perspectives are used in describing the
architecture. The four perspective includes; the Logical View, the Process View, the
Development View and the Use Case View.
 Logical View: under the logical view, we present the major component that
makes up the Peer Mentoring System. These include items such as the basic
operations of the system, the relationships between various sections of the

application and interactions. This will be expounded more by use of a sequence
diagram to visualize the flow of events on the system.
 Process View: having identified the operations and processes in the above logical
view, this view will be concerned with outlining the threads of control and
processes that are employed to execute the operations.
 Development View: this view presents an overview of the breakdown of key
modules to be developed. The view also explains how each module of the Peer
Mentoring System is organized with relation to the entire project
 Use Case View: the use case view details descriptions of various system use
cases. The use cases explain the functional objectives of the system step-by-step.
2 Design Goals
For the Peer Mentoring System, the usability of the system supersedes any other
requirement. As such, the priority of the design is how usable the system is more
important than re-usability of components (Osetskyi, 2019). The end goal is to have a
system that is efficient and easy to use; concern of how the code is organized is of low
priority.
Therefore, the design priorities for the Peer Mentoring System are:
 The design should result in a simple to use and efficient system
 The design should factor in data privacy and system usability at its core.
 The design should minimize complexity and enhance maintainability.
The design goals were arrived at after careful analysis of the user requirements and the
context of the system to be developed. For this case the system context and users are not
entirely IT experts and students may not all be tech savvy.
2.1 Background of the Design
Mentorship is a critical component of human development. In institutions of higher
learning, mentorship is critical to help students deal with social, professional and
academic challenges. For that reason, AIH seeks to develop an online mentorship system,
which allows mentors to easily interact with students on a wide range of issues.
The proposed Peer Mentoring System will help will facilitate a technology-driven
mentoring system within the institution. Traditionally, mentoring has been on a face-to-
face basis. However, with the technological advancements, and the uptake of IT in every
facet of human life, there is need to have an online system that can facilitate the
mentoring program (Satish and Makara, 2016). The system will have three key group of
users; the administrators, the mentors and the students. The admins will be responsible
for allocating mentors to the students. The Mentors performs the support and mentoring
to the students, while the students will be there to be mentored.
The main objective of the proposed Peer monitoring System is to help students with,
personal development, academic performance, reflection and Career Growth. The system
will form a platform where the mentors can easily interact and support students on a wide
range of areas that the students may be seeking help or mentorship on. The major
stakeholders are the students, mentors, admin, system developer and the project manager.

The design goal of this architectural design is usability; of the system supersedes any
other requirement. As such, the priority of the design is how usable the system is more
important than re-usability of components (Osetskyi, 2019). The end goal is to have a
system that is efficient and easy to use; concern of how the code is organized is of low
priority.
3 System Behavior
The proposed system requires that the admin collects all details of potential mentors and
students. The information is then used to create user accounts for each member. Since
mentorship is on academics and other areas, the administrator needs to add courses and
subject provided in each semester. For academic related mentorship, the admin assigns a
given group of students with a common subject matter to a relevant mentor (Satish and
Makara, 2016). For social and career mentorship, the admin assigns an individual student
to a certain mentor; a mentor can be assigned more than one student.
The system also takes in the makes obtained by students on each course. For academic
mentorship, the mentors can login into the system and view marks and grades obtained
by students whom they have been assigned to mentor. A mentor will therefore have
access to academic information of students he/she is mentoring. The mentor then starts
mentoring the student based on the performance on the given subject or course. Students
can access the system and interact with their mentors; by posting questions or seeking
guidance on challenges or advice on how to tackle a problem or how to improve
performance on the given subject.
The summary of the system behavior is therefore as follows;
 Admin collects information and creates user accounts; for mentors and students
 Admin assigns groups of students to a mentor as well as individual students to a
relevant mentor
 A mentor logs into the system; Views academic performance of students assigned
as well as rating and attendance data.
 Mentors can initiate mentorship by communicating with the group of students or
to individual student on the platform.
 Student on the other hand read and respond to the mentors; they also post
questions, seek guidance and assistance on tackling problems and issues.
 Mentors respond to student’s requests on the platform.

Figure 1.0 System behaviour
Each “dimension of system users will have their own interface and right to control and
alter the task data, for example, Admin is has the system rights to track the students being
mentored and can remark on it, the students themselves can change their details, see
progress, and submit their queries, requests and observations. The System will give a
response as input structure to all clients to give remarks or query or inquiries.
In PMS web-based application, the mentors can provide important services for the
growth of the students (Satish and Makara, 2016). Students are allocated mentor based on
their course, marks and attendance; or according to specific requests of the student. The
mentorship is designed to facilitate academic and professional growth of the students. For
that reason, students may be assigned mentors to specifically mentor them on career and
professional growth.
Users (Mentees) and Educators (Mentors) can Login from to the Peer Monitoring Portal
with their Student Id/Mentor ID and password. After logging in the system, Student are
able to edit their Profile, search Mentee, Apply for course help, look for internship, C.V.
development Program and likewise Mentors can Choose respective Mentees to guide
them through the program, Mentees can able to see Remarks, Attendance record, Course
enrolled of Mentees, Term of the year and course information (Satish and Makara, 2016).
This view of Mentor and Mentee will help each other to choose right guide as well it’s
easy to choose right mentees for the mentors too. Admin will act as the supervision on

this system, admin is able to block, delete and add information of mentors or mentees
information on the system. If there is any discrimination or harassment issues in future
between mentor and mentees, then Admin are able to manage both Mentor and Mentee
accounts”.
3.1 Functional and Non-Functional Requirements
 Performance; high performance in terms of easy of accessing features and
executing tasks (Satish and Makara, 2016).
 Capacity to handle a large number of students
 Availability: always available with minimal downtime
 Reliability: high reliability of the system.
 Security: security for data in transit through encryption.
 Backup plan: provide backup on site and out of site to ensure full recovery in case
of a problem.
4 Logical View
This section presents the main functional components of the Peer Mentoring System. The
specific functional components covered include; modules, the static relationships
between modules, and their dynamic patterns of interaction. We first express the modules
of the system in term of high level components (architecture) and progressively refine
them into more detailed components and eventually classes with specific attributes and
operations.
4.1 High-Level Design (Architecture)
The high level design architecture shows the components and their interactions on the
proposed Peer Mentoring System. The key components include the user interface, middle
tier, transport layer and data access objects. The User Interface is the boundary between
the system and its users (Satish and Makara, 2016). It is a critical component as its design
affects the success of the system. Middle Tier contains the Business Logic and Data
Processing layer. This component does the computations and decision making, as well as
processing requests from users. On the proposed system, this component will reside on
the server and will handle requests from the user interface; it will sit between the user and
the database. The data access component handles interactions with the databases; it
receives queries from the business logic component and connects with the database to
execute the queries. Data Storage is handled by a MySQL DBMS. The high level
architectural diagram is as show below;

Figure 1.1 High level architecture of the system
The second logical view if the overall system interaction with the 3 main users;
Figure 2.0 A high level view of the users interactions with the system.
The admin inputs students and mentors details, and assigns students to mentors. The
Studentts post their queries and request for mentorship and in return the system enables
them to view and interact with mentors. The mentors on the other hand receive from the
the sytem the marks and academic information of students assigned to them as well as

their queries and requests. The mentors user the system platform to respond to the queries
and requests.
System Components
Having visualized the system, users, interactions and boundaries, we delve deeper into
looking at the system components. The proposed system will have 5 key components;
 The User Interface: this is the boundary between the system and its users. It is a
critical component as its design affects the success of the system. For this system,
the user interface component will be developed using HTML, CSS, JavaScript
and JSP.
 Middle Tier: this tier can also be called the Business Logic and Data Processing
layer. This component does the computations and decision making, as well as
processing requests from users. On the proposed system, this component will
reside on the server and will handle requests from the user interface; it will sit
between the user and the database.
 A Transport Layer; this components handles data in transit from the client
interface [users GUI] and the business logic component. The component is critical
in ensuring data security through encryption and cryptographic signing to ensure
confidentiality and
 A Data Access Component: The data access component handles interactions
with the databases; it receives queries from the business logic component and
connects with the database to execute the queries.
 Data Storage: data storage for this case is handled by a MySQL DBMS. The
high level architectural diagram is as show below;
4.2 Mid-Level Design

Figure 1 Mid-Level design components and their relationships
For the user interface component, the key sub-components include the login page, the
home page which acts as the dashboard for the system and the three interfaces for each of
the user. The interface options are generated when the user logs into the system;
depending on the user type. For a mentor, the interface includes options to view all
students assigned to them, view individual student’s academic performance and view
queries sent by students. On the other hand, the admin will have more control over the
system; as such, the administrative interface contains options to add users, assign mentors
and view reports. For the student, the interface has fewer options; consisting of options to
send queries, view own academic performance data and read responses from the mentor.

Fig 4.0 the internal structure of the Peer Mentoring System Architecture (Satish and
Makara, 2016)
Internally, the system is designed to give overall control to the admin. The admin can
manage both the mentors and the students. On the other hand, the mentors have control
over students and play a critical role of mentoring and giving guidance to the assigned
students.
With regards to the development approach, the “Peer Mentoring System is developed as a
web-based system, which employs a Client and Server Model; utilizing two levels of
engineering that goes about as a connection between the guide and the understudy. PMS
is created on a User/server model that has a client application on user side and the
information source on the server side. This framework works under java runtime
condition utilizing total OOP (Object Oriented Programming) procedures to deal with
this present reality challenges in the framework. The total frontend is structured and
created with the assistance of J2EE engineering (Satish and Makara, 2016). The backend
information is dealt with by MySQL and for creating the required reports iReport
Designer is utilized. PMS works under two systems as Software and Hardware sides on
both client and server model” (Thakare, 2019)

Figure 2 Mentor/Student Interaction Sequence Diagram
As outlined in the diagram and explained earlier, the system supports mentorship on
academics and other areas; as such, student performance and courses taken are recorded.
To initiate mentorship, a mentor accesses the student’s academic performance to evaluate
the right kind of assistance to offer.
From the sequence diagram above, the mentors can login into the system and view marks
and grades obtained by students whom they have been assigned to mentor. A mentor will
therefore have access to academic information of students he/she is mentoring. The
mentor then starts mentoring the student based on the performance on the given subject
or course. Students can access the system and interact with their mentors; by posting
questions or seeking guidance on challenges or advice on how to tackle a problem or how
to improve performance on the given subject.
In this sequence diagram;
 The student logs into the system
 the system verifies the user and presents a homepage
 the student selects the option to send a query to the mentor
 The transport layer encrypts the request and sends to the business logic
 the business logic executes the query on the data access component
 the query is saved
 The mentor also logs into the system;
 The system presents a list of assigned student and their academic performances
the mentor responds to student’s queries on the system.

4.3 Detailed Class Design
The detailed entity-relationship diagram for the system is;
Figure 5.0 Entity relationship diagram.
The detailed class diagram of this application is derived from the above entity relationship
diagram.

5 Process View
The Process View is critical in helping to understand the separation of components and
subcomponents; as well as understand the communication mechanisms between the
components. This knowledge is critical in order to better optimize the dataflow within the
Peer Mentoring System. The knowledge is also necessary in designing the application as
we seek to develop a secure and stable system, which is thread safe and free of
exploitable vulnerabilities.
Each loop represents a thread of control.
Figure 6.0 Control threads of the application
User interface thread: this thread of control will be created when a user access the login
page of the application. The thread is responsive for displaying the application’s user
interface, as well as selecting the appropriate home page and features to display,
depending on the user type. For the admin users, the thread displays a home page with all
rights and privileges, while for other user types; the thread presents an interface with
appropriate and allowed options.
4.2 Application Thread
The application thread runs on the server. For the Peer Mentoring System, the application
thread will run on an Apache server and is the critical thread that is created at the start of
the application. This being a web-application, the application threads runs infinitely. It is
responsible for listening to client requests and generating appropriate responses for the

requests. The thread basically handles the basic system operation and it can be said to be
the engine or the heart that drives the Peer Mentoring System
4.4 Data Query Thread
The data query thread is auto created at the start of the application. The thread handles
communication with the database, querying of the database and controlling the number of
connections to the database, with the aim of avoiding overloading the system. The thread
is therefore a critical feature and besides querying the database, the thread performs load
balancing by limiting connections that would stall the application.
6 Development View
This view shows the system from the view of a software developer. For a developer a
system can be viewed in terms of packages that constitute the entire software. For this
application, the packages include the user interface package, the transport package that
handles data encryption and decryptions, the business logic component that executes all
the system computations, the data access component that acts as a load balancer for the
application, besides querying the database and the data storage component.
Figure 7.0 Package diagram of the application showing the various components

7 Physical View
This section presents the Peer Mentoring System as viewed by the system engineer. The
view shows the topology of the software components on the physical layer and the
physical connections between the components.
The peer mentoring system will be deployed on an internal server at the institution. Two
servers; a live server and a fail-over server will be used. Additionally, a cloud backup
will be used to provide offsite backup.
The system will run on a JBoss Server and will be served by a MySQL database. On the
client’s side, they will access the system by use of a web browser.
The physical view is as shown below;

8 Use Case View
Mentorship process Use Case:
1. Admin enter login credential
2. Verify login credentials
3. If successful, present the administrative interface
4. Add users; create user accounts [students, mentors]
5. assign student to mentor
6. save all details
Mentorship
1. Mentor login into the system;
2. Verify mentor login credentials
3. Display mentors home page
4. Show notifications of assigned students and queries
5. View student queries and academic performance
6. respond to queries
7. send queries
8. Save queries to database.
Student view
1. login into the system
2. Verify student login credentials
3. Display student home page

4. Display notification of assigned mentor
5. Show responses to mentorship queries and questions.
6. send queries and responses to mentor
Summary and Conclusion
This document has outlined and detailed the architecture and design of an online
Mentorship System. The proposed Peer Mentoring System will help will facilitate a
technology-driven mentoring system within the institution. Traditionally, mentoring has
been on a face-to-face basis. However, with the technological advancements, and the
uptake of IT in every facet of human life, there is need to have an online system that can
facilitate the mentoring program. The system will have three key group of users; the
administrators, the mentors and the students. The admins will be responsible for
allocating mentors to the students. The Mentors performs the support and mentoring to
the students, while the students will be there to be mentored.
The main objective of the proposed Peer monitoring System is to help students
with, personal development, academic performance, reflection and Career Growth. The
system will form a platform where the mentors can easily interact and support students on
a wide range of areas that the students may be seeking help or mentorship on. The major
stakeholders are the students, mentors, admin, system developer and the project manager.
In a bid to effectively analyses and present the architecture and design of the proposed
Peer Mentoring System, four different perspectives were used in describing the
architecture. The four perspective includes; the Logical View, the Process View, the
Development View and the Use Case View. Uunder the logical view, the design
document has presented the major component that makes up the Peer Mentoring System.
These include items such as the basic operations of the system, the relationships between
various sections of the application and interactions.
Having identified the operations and processes in the logical view, the process
view was concerned with outlining the threads of control and processes that are employed
to execute the operations. The main threads identified include; the user interface thread,
the application thread and data access thread. Under the development view, the document
has presented an overview of the breakdown of key modules to be developed. The view
also explained how each module of the Peer Mentoring System is organized with relation
to the entire project. The final view was the use case view, where details descriptions of
various system use cases were outlined. The use cases outline the functional objectives of
the system step-by-step.
The design goal of this architectural design is usability; of the system supersedes
any other requirement. As such, the priority of the design is how usable the system is
more important than re-usability of components. The end goal is to have a system that is
efficient and easy to use; concern of how the code is organized is of low priority.
Therefore, the design priorities for the Peer Mentoring System are:
 The design should result in a simple to use and efficient system
 The design should factor in data privacy and system usability at its core.
The design should minimize complexity and enhance maintainability.

References
Ahmad, T. 2012. Srs for School Management System. SOFTWARE
REQUIREMENTS SPECIFICATION (SRS), p.7.
Lennox Terrion, J., Leonard, D. and Philion, R. 2007. An Evaluation of a University
Peer-Mentoring Training Programme. International Journal of Evidence Based
Coaching and Mentoring, 5, p.42.
Satish, R.U.V.N. and Makaara, V., 2016. Implementation of Mentoring System Using
J2EE Architecture: E-Mentoring. International Journal of Electrical Electronics and
Computer Science Engineering, 3(5).
Thakare, S., Jadhav, S., Mane, I., Pawar, S. and Kulkarni, P. 2019. Online Mentoring
System (An Online Mentor-Student System). International Journal of Engineering
Trends and Technology (IJETT), 67(1).