Peer Mentoring System: Architecture and Design for AIH

Verified

Added on  2022/12/27

|20
|5205
|37
Report
AI Summary
This document outlines the architecture and design of a Peer Mentoring System developed for the Australian Institute of Higher Education (AIH). The system aims to facilitate technology-driven mentorship, addressing academic, professional, and personal development for students. It encompasses three key user groups: administrators, mentors, and students. The design prioritizes usability and efficiency, utilizing logical, process, development, and use case views to present the system's components, operations, and module organization. The system's behavior includes user account creation, mentor-student assignments, academic performance tracking, and communication features. The architecture is designed to be simple and efficient, ensuring data privacy and minimizing complexity. The ultimate goal is to provide an easy-to-use platform where mentors can support students on a wide range of issues.
Document Page
Peer Mentoring System
Architecture/Design Document
tabler-icon-diamond-filled.svg

Paraphrase This Document

Need a fresh take? Get an instant paraphrase of this document with our AI Paraphraser
Document Page
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.
Document Page
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
Document Page
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
tabler-icon-diamond-filled.svg

Paraphrase This Document

Need a fresh take? Get an instant paraphrase of this document with our AI Paraphraser
Document Page
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.
Document Page
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.
Document Page
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
tabler-icon-diamond-filled.svg

Paraphrase This Document

Need a fresh take? Get an instant paraphrase of this document with our AI Paraphraser
Document Page
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;
Document Page
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
Document Page
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
tabler-icon-diamond-filled.svg

Paraphrase This Document

Need a fresh take? Get an instant paraphrase of this document with our AI Paraphraser
Document Page
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.
Document Page
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)
chevron_up_icon
1 out of 20
circle_padding
hide_on_mobile
zoom_out_icon
[object Object]