College LMS: Session: BS Computer Science

College LMS
Session: BS Computer Science 2019-2023
Supervised By: Mr. Hassan
Submitted By:
Fatima Sughra
Hajra Riaz
COLLEGE LEARNING MANAGEMENT SYSTEM
Statement of Submission
This is to certify that Fatima Sughra and Hajra Riaz have successfully completed
the final year project named as: College Learning Management System (College
LMS) at the Quaid-i-Azam University, Islamabad, for the partial requirement of the
degree of BS in Computer Science.
Project Primary Advisor

Name: Mr. Hassan
Designation: Lecturer
IMCG F-6/2, Islamabad
QUAID-I-AZAM UNIVERSITY, ISLAMABAD Page | 2

Proofreading Certificate
It is to certify that I have read the document meticulously and circumspectly. I

am convinced that the resultant project does not contain any spelling,
punctuation or grammatical mistakes as such. All in all, I find this document well
organized and I
am in no doubt that its objectives have been successfully met.
-----------------------------------
Mr. Hassan
Department of Computer Science,
IMCG F-6/2, Islamabad

Acknowledgement
First of all, we want to thank ALLAH Almighty, the most gracious and merciful, for
all his blessings who guided us on the road to success from our childhood till the
completion of the project. Without his blessings it was impossible for us to come up
with complete solution.
We want to dedicate this study to our beloved parents who have dedicated us their
sleepless nights waiting for us and praying for our success. Without their solid faith
and belief in our abilities, this study was impossible.
We thank Quaid-i-Azam University, Islamabad and IMCG F-6/2 for running this
program and giving girls an opportunity as a career and a better future.
Mr. Hassan, our supervisor has been an invaluable asset for us. Her leadership,
inspiration and raw passion for innovating things has kept us on track even when we
were at our lowest. It is the credit to her guidance that we have succeeded to make this
project.
We also extend our thanks to other faculty for their cooperation during our project.

Abstract
College Learning Management System (LMS) is an online college management,

multi-purpose application which provides multiple services that help the colleges and
universities in managing learning activities.
In today’s society where things are getting automated quickly, the colleges also start
to moving towards modern technology. This application will allow the colleges to
manage college semester activities which includes student portal side where student
can check their progress in almost every sector, teachers can manage their side as well
in perspective of course content, attendance, class scheduling. Examination
department can manage their side of examination activities, librarian can manage their
library stuff like issuing books, returning books, adding to library and so forth finance
department can manage their side as well. Furthermore, it also allows the colleges to
efforts manage whole college with minimal efforts.
Security of college data in our application is our first priority. This application has
authentication-based accesses to the services which are required to use by any
department.
Most users want their personal information to be secured which is why we have used
middle ware in order to secure user data from one and other. This application also has
an easy-to-use interface.
It can assist the user to concentrate on their other activities rather to concentrate on the
record keeping. Thus, it will help organization in better utilization of resources. The
organization can maintain computerized records without redundant entries. That
means that one need not be distracted by information that is not relevant, while being
able to reach the information.
Our application also retains the data records which helps institutes to re visit them any
time and can keep it safe only accessible to the authorizes person.
From revenue point of view an owner of this application can set paid ads of any
advertising agency using our app.

List of Figures
Figure 1.1 Lifecycle of System................................................................ 14

Table of Contents
(i) List of Figures.................................................................. 6
(ii) Table of Contents............................................................ 7
1 Introduction and Overview..............................................................10
1.1 Introduction................................................................................. 11
1.2 Purpose....................................................................................... 11
1.2.1 Scope.......................................................................... 11
1.3 Motivation................................................................................... 11
1.4 Project Description......................................................................12
1.5 Existing System..........................................................................12
1.5.1 BZ Reminder..............................................................13
1.5.2 Calendar Notify..........................................................13
1.5.3 Ike.............................................................................. 13
1.6 Proposed System......................................................................... 14
2 Background....................................................................................... 15
2.1 Android....................................................................................... 16
2.2 Android Architecture..................................................................16
2.3 Linux Kernel............................................................................... 17
2.4 Libraries...................................................................................... 17
2.5 Android Runtime........................................................................17
2.6 Android Framework....................................................................17
2.7 Applications................................................................................ 18
3 Feasibility Report.............................................................................19
3.1 Feasibility Report........................................................................20
3.1.1 Technical Feasibility..................................................20
3.1.2 Operational Feasibility...............................................21
3.1.3 Economic Feasibility.................................................22
4 Requirement Analysis......................................................................23
4.1 Requirement Analysis.................................................................24
4.2 Types of Requirements...............................................................24
4.2.1 Functional Requirements...........................................25
4.2.2 Non-Functional Requirements...................................26

4.3 Requirement Specifications........................................................27

4.3.1 Software Specifications..............................................27
4.3.2 Hardware Specifications............................................27
5 Architecture and Design..................................................................29

5.1 Architectural Design...................................................................30
6 Android Framework Components..................................................33

6.1 Introduction to Android Framework...........................................34
6.1.1 Android Manifest.xml................................................34
6.1.2 Activities....................................................................35
7 Use Case Diagrams........................................................................... 37

7.1 Use Case Diagram....................................................................... 38
7.1.1 Importance.................................................................38
7.1.2 Components...............................................................38
7.2 Use Case Scenarios.....................................................................40
8 UML Diagrams................................................................................. 53
8.1 UML Diagram............................................................................. 54
8.1.1 Sequence Diagram.....................................................54
8.2 Class Diagram............................................................................. 64
8.2.1 Purpose of Class Diagram..........................................64
9 Screen Shots...................................................................................... 66
9.1 Android Studio Codes.................................................................67
9.2 User Interface.............................................................................. 73
10 Testing............................................................................................... 97
10.1 Software Testing.........................................................................98
10.1.1 Unit Testing.............................................................98
10.1.2 Integration Testing..................................................99
10.1.3 Performance Testing................................................99
10.1.4 System Testing........................................................99
10.2 Test Cases................................................................................... 99

11 Conclusion and Future Prospects.................................................102

11.1 Conclusion................................................................................103
11.2 Future Work.............................................................................. 103
12 Bibliography................................................................................... 104

CHAPTER 1
INTRODUCTIO
N AND
OVERVIEW

1.1 INTRODUCTION
As in the Modern era where everyone is busy in their lives, mobile phones have
become an important part of life. Having a crisis situation due to great distraction
around is a serious problem and need a helping hand to solve the problem. If you have
mis your important meeting or any important thing having these apps on your mobile
phone can diminish your risk and bring assistance when you require it. In the light of
ever-increasing fast life, you need a helping hand that can help you have control on
your tasks, so a swarm of new apps have been developed to provide belling system to
people on their phones.
1.2 PURPOSE
The purpose of Automatic College Bell System (ACBS) is to:
 Provide assistance and help scheduling the tasks to the institutes.

 Construct a recherche application that doesn’t face any critic at any situation.
 Give a flexible, easily manageable, less time consuming and perdurable
application.
 Make the institute handle the application with ease and comfort.
1.2.1 SCOPE
 Through this application user can schedule notification with note, bell the
phone / hardware device with note, find the current, overdue and future tasks,
set the note and ring bell (even on silent mode) on the scheduled time and date.
 Institutes will also be able to set favorite tasks also repeat that it with multiple
options like in minutes, hours, days, weeks, months, and years.
 This application will be helpful in multiple situations i.e. Shopping, meeting,
traveling, writing, reading and so on.
 This application has the Bluetooth option to connect to any Bluetooth powered
device.
 This application also has authentication module which ensures the security and
integrity.
 The App uses firebase authentication which is state of the art authentication
facility.
1.3 MOTIVATION
As much as we would like to get rid of them, situations are unavoidable and usually
regretful. The nature and consequences of these situations can vary significantly and
in worst cases can also be in great loss of both financially and psychologically.
Therefore, it would be nice to have some mechanism by which we can remember our

tasks, our important meetings in it. The need for such a mechanism increases even
more as in this era of technology, platforms exist to support them. One and a very
common one in that is a Smartphone. Almost everyone today carries a Smartphone, as
they have become more and more affordable and easily available. Also, within the
Smartphone market, Android is the clear leader in terms of market share. According to
one report, 82.7 % of the total Smartphones sold in 2020 were the Smartphones that
run on Android Operating System. Hence developing an Android application becomes
an obvious choice.
1.4 PROJECT DESCRIPTION

The Automatic College Bell System is a Bell and Notification based application that is
meant to run on Android devices smartphones. The main functions and features of the
application are:
 Once the application is launched, the user is directed to the login page where he
/ she enters the right credentials after that main screen where he will have to
give permission to access the ringtones and the notification first to continue
using application. The user then will be on the home screen where he/she has
option to add new reminder or to see the all previous added reminder in all tab
and the home screen also have the favorites tab to see the important reminders
after clicking the add option the user will be asked to fill the fields like (adding
note, selecting date, time, repeat, marker report as, etc.).
 The user has two option to select in order to view the reminder one is by
selecting bell to ring with the reminder note and other one is the notification
which will pop up in notification bar with the note status.
1.5 EXISTING SYSTEMS

As we all know that through belling application, we can get ring alarm by signing in
with our Gmail account but that don’t have the reminder note option as well the
scheduling sequence.
As a part of literature survey, we investigated some applications that offer the same or
similar services for android and other platforms. The aim is to see how these
applications work and to see how they can be improved. Today the need of reminder
application is growing as people most of time forget things that can be important to
their life, family, business and health. In these types of cases, a smart phone plays an
important role for reminding. Now android is budding on some apps for security
purpose. These apps are as follows:

1.5.1 BZ Reminder
BZ reminder is the android mobile application, a closed source paid app that helps
user’s setup to-do lists.
In terms of features, Bz reminder is pretty simple. It allows user to select time, date,
and note input; it can be uninstalled. send alarm to users via popups.
Once you are into BZ reindeer you can do following:
 Select data in the date panel for the alarm and the ringtone to ring.
 Select Time from time panel and the sequence in which it will be alarmed.
 Lastly you can see the scheduled notes that are being added all in the same view
without portion.
1.5.2 Calendar Notify

Calendar Notify (doesn’t work for Android 2.6 and below versions) is an average
calendar app and a reminder app. It syncs only with Google Calendar and cannot be
used on both. This app is paid and also have a free version but with limited options.
 Makes your phone ring, even if left on silent or vibration mode.

 Show user the text of the note.
 It helps user to schedule to-do-list on own specification.
 Battery and CPU usage of this app is high.
1.5.3 Ike
Ike To Do List is another reminder app. The app comes with reminders, due dates,
images, audio, notes, widgets, customization, and more. It definitely covers all of the
basics and does so in a fun way. The pro version goes for $1.99 and unlocks all
themes, widgets, and some additional features.
Key features include:
 This app helps in setting up the reminders.

 Reminders contains notes, date and time.
 It creates widgets to help user with more convince.
 Battery and CPU friendly.
 Pre-installation required.
 No Remote control from any other phone.
 Makes you phone ring, even if left on silent mode.

1.6 PROPOSED SYSTEM

The system we are going to propose is software application which will give us the
reminder note, ring bell even on silent mode, allow add favorite notes, user can see
current notes, it also allows setting up the basic thing like ringtone, future due
reminders, it helps sharing the application, setting up adds for revenue perspective.
Figure 1.1 Lifecycle of System
If user want set reminder of choice, user in application will first add the reminder with
the required fields and after that all reminders can be shown in All tab one the time is
reached it will bell the user or notify it with notification.
In this application, user will have automatic response from the reminder mobile app
after reaching on a specific defined time. If user wants to ring a bell on any time,
application will ring the bell even in silent mode and if bell is stopped before user gets
to the mobile, the application will repeat itself after few minutes automatically to the
mobile.
Similar is the case with notifications, if someone does not open the notification on the
mobile, user will be notified after few minutes again automatically.

CHAPTER 2
BACKGROUND

2.1 ANDROID
Android is one of the most widely used Mobile Operating
System today. It is a software bunch comprising not only
of the Operating System but also middleware and key
applications. Some of the most important features of an
Android operating system is that it enables reuse and
replacement of components, it is optimized for mobile
devices and tablets, it is based on the open source Web kit Figure 2.1 Android Logo
engine and supports 2-D and 3-D graphics using OpenGL-
ES standard.
2.2 ANDROID ARCHITECTURE

The Android operating system is implemented as a stack of different layers of software.
The following image depicts these different layers:
Figure 2.2 Android Architecture

2.3 LINUX KERNEL

This is the layer at the very bottom of the Android architecture. All other layers run on
top of the Linux kernel and rely on this kernel to interact with the hardware. This layer
contains all the essential hardware drivers which help to control and communicate
with the hardware. It provides the basic functionality like Process Management,
Memory Management and Device Management like Camera, Display, Flash etc. The
features of Linux kernel are:
 Security: The Linux kernel handles the security between the application and the
system.
 Memory Management: It efficiently handles the memory management thereby
providing the freedom to develop our apps.
 Process Management: It manages the process well, allocates resources to
processes whenever they need them.
 Network Stack: It effectively handles the network communication.
 Driver Model: It ensures that the application works properly on the device and
hardware manufacturers responsible for building their drivers into the Linux
build.
2.4 LIBRARIES
This is a set of common functions of the application framework that enables the
device to handle different types of data. Some of the most important set of libraries
that are included are – Web kit which is the browser engine to display HTML,
OpenGL used to
render 2D or 3-D graphics on to the screen, SQLite which is a useful repository for
storing and sharing of application data.
2.5 ANDROID RUNTIME

The Android runtime mainly consist of the Dalvik Virtual Machine (DVM). DVM is
very much like the standard Java Virtual Machine (JVM) except that it is optimized
for mobile devices that have low processing power and low memory. DVM generates
a .dex file from the .class file at compile time and provides higher efficiency in low
resources devices. Each application has its own process and an instance of DVM.
Android runtime also provides core libraries that enable the Android developers to
create applications using the Kotlin and Java language.
2.6 ANDROID FRAMEWORK

Application Framework provides several important classes which are used to create an

Android application. It provides a generic abstraction for hardware access and also
helps

in managing the user interface with application resources. Generally, it provides the
services with the help of which we can create a particular class and make that class
helpful for the Applications creation.
It includes different types of services activity manager, notification manager, ring
manager, view system, package manager etc. which are helpful for the development of
our application according to the prerequisite.
2.7 APPLICATIONS
Applications is the top layer of android architecture. The pre-installed applications
like home, contacts, camera, gallery etc. and third-party applications downloaded from
the play store like chat applications, games etc. will be installed on this layer only. It
runs within the Android run time with the help of the classes and services provided by
the application framework.

CHAPTER 3
FEASIBILITY
REPORT

3.1 FEASIBILITY REPORT

A feasibility report is the result of a detailed examination of a proposed idea, project
or business to determine if it is likely to be successful.
It can also be defined as:
“It is an assessment of a practicality of a proposed plan or method. Which helps to
find the strengths and weaknesses of an existing business or proposed venture,
opportunities and threats present in the environment, the resources required to carry
through, and ultimately the prospects for success.”
The main objective of the feasibility study is to test the Technical, Operational and
Economical feasibility for adding new modules and debugging old running system.
Preliminary investigation examines -project feasibility; the likelihood the system will
be useful to the organization. A feasibility- study assesses the operational, technical
and economic merits of the proposed project. The feasibility study is intended to be a
preliminary review of the facts to see if it is worthy of proceeding to the analysis
phase. From the systems analyst perspective, the feasibility analysis is the primary
tool for recommending whether to proceed. to the next phase or to discontinue the
project.
A feasibility study should provide management with enough information to decide:
 Whether the project can be done?

 Whether the final product will benefit its intended users and Organization?
 What are the alternatives among which a solution will be chosen?
 Is there a preferred alternative?
There are following aspects in the feasibility study portion of the preliminary
investigation:
1. Technical feasibility
2. Operational feasibility
3. Economic feasibility
3.1.1 Technical Feasibility

A large part of determining resources has to do with assessing technical feasibility. It
considers the technical requirements of the proposed project. The technical
requirements are then compared to the technical capability of the organization. The
systems project is considered technically feasible if the internal technical capability is
sufficient to support the project requirements.

The essential questions that help in testing the operational feasibility of a system
include the following:
a. Is the project feasible within the limits of current technology?
Yes, the project is feasible, the current technology is well known and already in
use.
b. Does the technology exist at all?
The software and hardware requirements for the development of this project
are not many and can be easily available.
c. Are the required frameworks available?
The current frameworks are well known and already in use. Many
commercially big applications have already been developed using it. No
hardware required for the project.
d. Can they be upgraded to provide the level of technology necessary for the new
system?
Yes, they can be upgraded to provide the level of technology necessary for the
new system.
3.1.2 Operational Feasibility

Operational Feasibility is dependent on human resources available for the project and
involve projecting whether the system will be used if it is developed and
implemented.
Proposed projects are beneficial only if they can be turned out into information system
that will meet the organization's operating requirements. Operational feasibility
aspects of the project are to be considered as an important part of the project
implementation. Some of the important issues raised are to test the operational
feasibility of a project includes the following:
a. Will the system be used and work properly if it is being developed and
implemented?
This system after approval will be published and used, and will be beneficial for
each stakeholder.
b. Will there be any resistance from the user will undermine the possible
applications benefits?
So there is no question of resistance from the users that can undermine the
possible applications benefits.

3.1.3 Economic Feasibility

A system can be developed technically and that will be used if installed must still be a
good investment for the organization. In the economic feasibility, the development
cost in creating the system is evaluated against the ultimate benefit derived from the
new systems. Financial benefits must equal or exceed the cost. This is often called a
cost- benefit analysis.
No monetary expenses are required in this project as well be using open source
technology and built-in frameworks which are freely available. We will customize the
built-in solutions and implement the logic.

CHAPTER 4
REQUIREMENT
ANALYSIS

OVERVIEW
This chapter gives details of the requirements of the project under development,
Automatic College Bell System. Requirements are the capabilities and conditions to
which the system and broadly, the project must conform. Hence, the complete
understanding of requirements is essential for the success of any application
development effort.
4.1 REQUIREMENT ANALYSIS

Requirement Analysis, also known as Requirement Engineering, is the process of
identifying requirements of the user. These are the services that the system is expected
to provide and the constraints on these services. Requirements analysis is a software
engineering action that begins during the communication activity i.e. Communication
with the client, that continues into the modeling activity. The requirements should be
complete and consistent. Complete means that there should be description of all
requirements of the system and consistent refers to the fact that there should not be
any contradiction or conflict within the system.
4.2 TYPES OF REQUIREMENTS

Requirements are categorized in several ways. The following are common:
1. Functional Requirements:
These are a description of the services that the system is required to provide i.e.
how the system will react to particular inputs, how it will behave in particular
situations, etc. Functional software requirements help you to capture the
intended behavior of the system. In some cases, functional requirements also
explicitly state as to what the system will do. The advantages of functional
requirements are:
 Helps you to check whether the application is providing all the

functionalities that were mentioned in the functional requirement of that
application
 Functional requirements along with requirement analysis help identify
missing requirements. They help clearly define the expected system
service and behavior.
 Errors caught in the Functional requirement gathering stage are the
cheapest to fix.
 Support user goals, tasks, or activities for easy project management.

2. Non-Functional Requirements:
The definition for a non-functional requirement is that it essentially specifies
how the system should behave and that it is a constraint upon the systems
behavior. A non-functional requirement is essential to ensure the usability and
effectiveness of the entire software system. One could also think of non-
functional requirements as quality attributes of a system. The benefits of Non-
functional requirements are:
 The nonfunctional requirements ensure the software system follow legal

and compliance rules.
 They ensure the reliability, availability, and performance of the software
system
 They ensure good user experience and ease of operating the software.
 They help in formulating security policy of the software system.
4.2.1 FUNCTIONAL REQUIREMENTS

The major functional requirements for the Automatic College Bell System are:
 The user of the application should see the login screen which contain the
username and password field and login button after successful login user
should see home Screen.
 The user of the application should see the main screen which contain the All
and Favorite tab, Bluetooth connectivity button and logout in the home Screen.
 The user must see on the main screen where various buttons are present to
perform tasks (All, Favorites, Add, Menu, Search, Adds, etc.).
 User can create new reminder by clicking the Plus icon in the bottom of the
main screen.
 User will be able to fill the required filled in the set Reminder screen where
he/she needs to provide Note, Date, Time, Repeat, Marker and Report as and
then click the yellow tick to finish the reminder setting up.
 User will able to create either notification or ring Bell for the reminder. A
notification or bell ring will be provided to show the reminder text.
 After setting the reminder and other features of the application, the user will be
able to see Calendar, Done Tasks, Over Due, Today Task, Tomorrow Task,
Upcoming Task and Setting in menu option of the application.
 The system will be able to recognize the time and date reminder history and
will be able to give response to the mobile phone.

 User will have the access to turn off and on the reminder bell and also change
the status of reminder that can in overdue, or postponed.
 User can connect other Bluetooth powered devices by using Bluetooth option.
 User can logout using the logout button.
4.2.2 NON-FUNCTIONAL REQUIREMENTS

Non-functional requirements just examine the operation of the system instead define the
specific behavior of the system.
It includes:
1) Functionality
 Validation Rule
 Edit, update
2) Usability
 The customer will have a user-friendly interface, so that he can easily find
all the features of the application.
 Automatic College Bell System is easy to use for every type of users
without any training.
3) Reliability
The application should ensure that the user actions are performed correctly as:
 If the user has entered invalid data at the time of adding reminder, his/her
will be notified at once.
 The application will be available all the time and user will also get
response from application in the form of notifications in return of the action
performed.
4) Performance
 The system shall give response in minimum possible time.
 The system shall easily be installed.

5) Supportability
 Comments will be used in code so it can easily be understandable at any time.
 Relevant and same type of files will be maintained in respective folders.
6) Security
 Secure access of private data (user’s keywords).
7) Extensibility
 Automatic College Bell System will be highly desirable for future extensions.
4.3 REQUIREMENT SPECIFICATIONS

A Requirements Specification for a software system is a complete description of the
behavior of a system to be developed.
4.3.1 SOFTWARE REQUIREMENTS:

These requirements are separated based on whether you are developing the app or
running the app on a device.
For development:
Operating System: Windows XP or higher / Mac OS X 15.8 or later / Linux Platform:
Android Studio 3.0.0 or higher
Tools:
1. Android Studio
2. Adobe Photoshop CS6
3. Visual Paradigm
4. Android Emulator
For running on a device:
1. Operating System: Android 4.0 or higher
2. Cellular capabilities for notification messages
4.3.2 HARDWARE REQUIREMENTS:
For development: Processor:
Intel Pentium IV or higher RAM: 256 MB
Space on disk: 250 MB (at the least)

For running on a device:

Device: Phone or tablet running Android 4.0 or higher
Disk space: 15 MB (at the least)

CHAPTER 5
ARCHITECTURE
&
DESIGN

OVERVIEW
After careful analysis of the requirements of the proposed system, the design for the
application is described in this chapter. The previous chapters defined what is required
and needed in the Automatic College Bell System. In this chapter the architectural
design of the Offline Mobile Finder is proposed.
5.1 ARCHITECTURAL DESIGN

Architectural Design is the framework that describes the components of a system and
how they all combine together to form the structure of the system. According to
Sommerville,
“Architectural Design is a creative process where you try to establish a system
organization that will satisfy the functional and non-functional system requirements.”
Architectural Design is responsible for representing the data of the system and also the
program components that are required to build a computer-based system.
Figure 5.1 Architectural Design of Automatic College Bell System

The different components in the architecture are
 User:
This is the person who installs the application on his Android device. The user
provides various inputs like reminder note, and details etc. and triggers various
events on the application.
 Front End
This is the part of the application that is visible to the user. A screen presented
to the user is usually an Activity, Fragment or a Dialog Box. They contain
various elements like text box or buttons to take inputs from and provide
outputs to the user.
 Logic
These are the Code files that contain the logic of the application. They contain
various methods and classes that meet the functional requirements of the
application. These files also contain code to communicate with other
components in the application.
 Services
This is the component of the application that is typically used to perform long
background tasks that do not have a user interface. For example – a service is
used to play bell at the device even when bell activity is not on the screen.
 Receivers
This is the component of the application that typically listens for some events
or responses from other services. For example – A receiver is used to fetch the
reminder note and then perform the respective task.
 SQLite
Android platform provides libraries for SQLite database. An SQLite database
is a relational database that is local to an Android device. It requires no
configuration and is available to use for an app developer. For example –
SQLite is used in the app to store various information about a bell.

 Bell Manager
It is used to fetch the bell or alarm of the Android device. The fused bell
provider API uses system object—just like the time framework API—to fetch
the time and data also the note with it. The API provides features to listen for
ring tone updates as well as to get the last known bell reminder. All these
features make the fused bell provider API a good candidate to replace the
components that use the framework alarm API with minimal changes to the rest
of the app.
 Notification Manager
It is used to manage notification operations such as sending notification and
text. For example, sending notification to the mobile phone from which the
reminder is setup.
 Authentication Manager
It is used to manage authentication properties. Authentication is managed by
firebase auth which includes on both on client side as well as on admin side.
For example, when new user opens up the app, he / she first need’s to login
with the correct credential’s username and password which will be than
authenticated from firebase cloud and upon correct insertion it will be
authenticated to the home page.

CHAPTER 6
ANDROID FRAMEWORK
COMPONENTS

6.1 INTRODUCTION TO ANDROID FRAMEWORK

Android applications are written in Java, ReactJs, Flutter and Kotlin. There are
different integrated environments (IDEs) that can be used to develop Android apps.
The Automatic College Bell System (ACBS) application is developed in Android
Studio using Android software development kit (SDK). SDK tools create an Android
package (.apk) that contain all the necessary resources to install and run the app. Each
app runs as a separate process in the underlying Linux kernel and behaves like a
separate user. Files within an app can be run only by the specific user id assigned to
the app. Each app also has its own instance of the Dalvik Virtual Machine (DVM). In
order for the apps to share data with other apps like system services we have to assign
permissions to the app during install time. This is done by adding the required
permissions in the Manifest file.
6.1.1 Android Manifest.xml:

The AndroidManifest.xml (Manifest) file provides important information to the
Android system to run the app. All the components have to be declared in the
Manifest file for the Android system to be able to instantiate them. The Manifest file
also contains the various permissions needed by the application, API libraries that the
app is linked other hardware and software features that the app uses and also the
minimum API Level supported by the app.
Project Android Manifest.XML

<?xml version="1.0" encoding="utf-8"?>
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
xmlns:tools="http://schemas.android.com/tools"
package="com.qrolic.reminderapp">
<uses-permission android:name="android.permission.USE_FULL_SCREEN_INTENT" />


<uses-permission android:name="android.permission.SYSTEM_ALERT_WINDOW" />

<uses-permission android:name="android.permission.RECEIVE_BOOT_COMPLETED" />

<uses-permission android:name="android.permission.CALL_PHONE" />
<uses-permission
android:name="android.permission.WRITE_SETTINGS"
tools:ignore="ProtectedPermissions" />
<uses-permission android:name="android.permission.INTERNET"/>
<application
android:allowBackup="true"
android:icon="@mipmap/ic_launcher"
android:label="@string/app_name"
android:roundIcon="@mipmap/ic_launcher_round"
android:supportsRtl="true"
android:theme="@style/Theme.ReminderApp">
<activity android:name=".activity.SearchActivity"
android:screenOrientation="portrait"></activity>
<activity android:name=".activity.CalendarDayActivity"
android:screenOrientation="portrait"/>

<activity
android:name=".activity.BootActivity"
android:screenOrientation="portrait"
android:theme="@style/Theme.Transparent" />
<activity android:name=".activity.AlarmActivity"
android:screenOrientation="portrait">
>
</activity>
<activity android:name=".activity.AddNewReminder"
android:screenOrientation="portrait"/>
<activity
android:name=".activity.HomeActivity"
android:screenOrientation="portrait"
android:label="@string/title_activity_home"
android:theme="@style/Theme.ReminderApp.NoActionBar"
android:windowSoftInputMode="adjustNothing" />
<activity android:name=".activity.SplashActivity"
android:screenOrientation="portrait">
<intent-filter>
<action android:name="android.intent.action.MAIN" />
<category android:name="android.intent.category.LAUNCHER" />

</intent-filter>
</activity>
<receiver android:name=".util.MyBroadCastReciver">
<intent-filter>
<action android:name="android.intent.action.BOOT_COMPLETED" />
</intent-filter>
</receiver>
<meta-data
android:name="com.google.android.gms.ads.APPLICATION_ID"
android:value="@string/google_ads_application_id"/>
</application>
</manifest>
6.1.2 Activities:
An Activity is the component of an Android app that is presented to the user and
responsible for interacting with them. The Activity may cover the entire screen of the
device or may only cover a part of the screen displaying on top of another Activity.
An Android app is a collection of loosely coupled activities along with other resources
where one Activity can call another Activity at any point usually using Intents. When
an Activity starts another Activity, the earlier Activity is pushed on to a back stack.
The back stack is a Last in – First out (LIFO) structure supported by the Android
system for every app. When the user starts a new Activity, it is pushed on the top of
the stack and displayed to the user, when the user is done with the Activity and
presses the back button, this Activity is popped from the stack and the user sees the
earlier Activity. An Activity implements a number of callback methods that are
invoked by different events during the lifecycle of an Activity.

The following diagram shows the various callback methods for an Activity.
Figure 6.1 Activity Life Cycle

CHAPTER 7
USE CASE DIAGRAMS

7.1 USE CASE DIAGRAM

A use case diagram at its simplest is a representation of user’s interaction with the
system and depicting the specifications of a use case. A use case diagram can portray
the different types of users of a system and the various ways that they interact with the
system. This type of diagram is typically used in conjunction with the textual use case
and will often be accompanied by other types of diagrams as well.
A use case diagram is a dynamic or behavior diagram in UML. Use case diagrams
model the functionality of a system using actors and use cases. Use cases are a set of
actions, services, and functions that the system needs to perform. In this context, a
"system" is something being developed or operated, such as an android app. The
"actors" are people or entities operating under defined roles within the system.
While a use case itself might drill into a lot of detail about every possibility, a use case
diagram can provide a higher-level view of the system. It has been said before that
“Use case diagrams are the blueprints for your system”. They provide the
simplified and graphical representation of what the system must actually do.
7.1.1 IMPORTANCE
Use case diagrams are valuable for visualizing the functional requirements of a system
that will translate into design choices and development priorities.
They also help identify any internal or external factors that may influence the system
and should be taken into consideration.
They provide a good high-level analysis from outside the system. Use case diagrams
specify how the system interacts with actors without worrying about the details of
how that functionality is implemented.
7.1.2 COMPONENTS
A use case diagram contains four components.
 The boundary, which defines the system of interest in relation to the world around it.
 The actors, usually individuals involved with the system defined according to their
roles.
 The use cases, which are the specific roles played by the actors within and around
the system.
 The relationships between and among the actors and the use cases.

Figure 7.1 Use Case Diagram of Automatic College Bell System

7.2 USE CASES SCENARIOS

A use case has multiple “paths” that can be taken by any user at any one time. A use
case scenario is a single path through the use case.
Fully dressed use cases are stated below:
1. Launch Application
Use Case ID: UC-01
Use Case name: Launch Application
Use Case created by: Laiba & Ishrat
Use Case created on: 1st January 2022
Use Case updated on: 1st January 2022
Use Case updated by: Laiba & Ishrat
Use case Description: This use case describes that how the user will launch the
application.
Primary Actor: App User
Stake Holder and Interests: User wants to launch the application
Pre-condition:
1. Phone must have Android Jelly Beans or higher.
2. The application must be installed properly.
Main Success Scenario:
User Action System Response
User Clicks the

1. Application icon.
The Application Launches

2.
Successfully
Post Condition: Application Successfully launched

Alternative Flows: Application does not start, and an error is displayed
Priority: High.
Frequency in use: Most frequent

2. Login the Application

Use Case ID: UC-02
Use Case name: Log In
Use case Description: This use case describes the user login using the email and
password given during registration.
Login using:
 Email
 Password
Stake Holder and Interests: User wants to continue using Application.
Pre-condition:
1. User is registered.

User enters email and
1. password.
System validates the email and

2. password.
Successful login and displays

3. welcome screen.
Post Condition: User is successfully logged in the application.

Alternative Flows:
 Account does not exist message.
 Invalid/Wrong Password message.
Priority: High.

3. Create New Bell Reminder

Use Case ID: UC-03
Use Case name: Create new bell reminder
Use case Description: This use case describes that the user wants to create a new bell
reminder in the application.
Stake Holder and Interests: User wants to continue using Application.
Pre-condition:
1. User is registered.

User clicks the new
1. Bell button.
Application opens the new bell

2. options page.
User enters the
reminder content,
3. date, time, marker,
repeat as, reminder
type and clicks the
save button.
Application validates the details and
saved them successfully displaying
4. message.
Post Condition: User bell reminder is set successfully.

Alternative Flows:
 Account does not exist message.
 Invalid/Wrong Password message.
Priority: High.


4. Connect Using Bluetooth Option
Use Case ID: UC-04
Use Case name: Connect using Bluetooth option
Use case Description: This use case describes the user can use different Bluetooth
option to connect to a Bluetooth powered application in order to perform particular task
on the Physical Bell.
Tasks include:
 Click Bluetooth Button
 Click Open Bluetooth Button and set permission
 Click Close Bluetooth Button
 Click Connect Bluetooth Button
 Click Show Connected Bluetooth Devices.
Stake Holder and Interests: To connect to physical bell using Bluetooth
Pre-condition: Login
User click connect

1. Bluetooth button.
Application open ups the Bluetooth

2. option page.
3 User can see four option

and can select any of them
to perform specific task
related to that option

Post Condition: User can connect to physical bell successfully.

Alternative Flows: User cannot connect due to invalidity of the field.
Priority: High.
5. Done Tasks
Use Case ID: UC-05
Use Case name: Done Tasks
Use case Description: This use case describes that the user wants to see the Done Bell
Reminders in the application.
Stake Holder and Interests: App User see the done tasks.
Pre-condition: None
User clicks the Done

1.
Task button.
Application show the done tasks to

2. the user.
Post Condition: Application shows done tasks successfully.

Alternative Flows:
 Application didn’t show done tasks due to error.
Priority: High.

6. Overdue Tasks
Use Case ID: UC-06
Use Case name: Overdue Tasks
Use case Description: This use case describes that the user wants to see the Over Due Bell
Stake Holder and Interests: App User see the overdue tasks.
Pre-condition: None
User clicks the

1.
overdue button.
Application show the overdue tasks

2. to the user.
Post Condition: Application shows overdue tasks successfully.

Alternative Flows:
 Application didn’t show overdue tasks due to error.
Priority: High.
7. Today’s Tasks
Use Case ID: UC-07
Use Case name: Today’s Tasks


Use case Description: This use case describes that the user wants to see the Today’s Bell
Stake Holder and Interests: App User see the Today’s tasks.
Pre-condition: None
User clicks the

1.
Today’s Task
button.
Application show the Today’s tasks
2. to the user.
Post Condition: Application shows Today’s tasks successfully.

Alternative Flows:
 Application didn’t show Today’s tasks due to error.
Priority: High.
8. Tomorrow’s Tasks
Use Case ID: UC-08
Use Case name: Tomorrow’s Tasks
Use case Description: This use case describes that the user wants to see the Tomorrow’s Bell
Stake Holder and Interests: App User see the Tomorrow’s tasks.
Pre-condition: None

User clicks the

1.
Tomorrow’s Task
button.
Application show the Tomorrow’s
2. tasks to the user.
Post Condition: Application shows Tomorrow’s tasks successfully.

Alternative Flows:
 Application didn’t show Tomorrow’s tasks due to error.
Priority: High.
9. Upcoming Tasks
Use Case ID: UC-09
Use Case name: Upcoming Tasks
Use case Description: This use case describes that the user wants to see the Upcoming Bell
Stake Holder and Interests: App User see the Upcoming tasks.
Pre-condition: None
User clicks the

1. Upcoming Task
button.
Application show the Upcoming
2. tasks to the user.

Post Condition: Application shows Upcoming tasks successfully.

Alternative Flows:
 Application didn’t show Upcoming tasks due to error.
Priority: High.
10. Logout Tasks
Use Case ID: UC-10
Use Case name: Logout Tasks
Use case Description: This use case describes that the user wants to logout from the
application.
Stake Holder and Interests: App User want to logout.
Pre-condition: None
User clicks the logout

1. button.
Application show the logout to the

2. user.
Post Condition: Application logout successfully.

Alternative Flows:
 Application didn’t logout due to error.
Priority: High.
11. Register User Tasks

Use Case ID: UC-11
Use Case name: Register User Tasks
Use case Description: This use case describes that the admin user register’s the app user from
the web application.
Primary Actor: Admin User
Stake Holder and Interests: Admin User want to Register app user account.
Pre-condition: None
Admin User clicks

1. add user button in
web application.
Application show the form to the
2. admin user.
3 Admin enter username

and password of the user
and click the save button.
App user successfully register the

4 user.
Post Condition: Admin User Register app user account successfully.

Alternative Flows:
 Application does due to error.
Priority: High.
12. Reset User Password Tasks

Use Case ID: UC-12

Use Case name: Reset User Password Tasks
Use case Description: This use case describes that the admin user resets app user password
from the web application.
Stake Holder and Interests: Admin User want to reset the app user account password.
Pre-condition: None
Admin User clicks

1.
reset password
button in web
application.
Application show the email of app
2. user to the admin
user.
3 Admin conforms the app
user detail and click the
reset email send button.
Web app successfully sends the reset

4 password link in
email to the app user.
Post Condition: App user resets account’s password successfully.

Alternative Flows:
Priority: High.
13. Ban App User
Use Case ID: UC-13
Use Case name: Ban app user

Use case Description: This use case describes that the admin user ban app user account the
web application.
Stake Holder and Interests: Admin User want to ban the app user account.
Pre-condition: None
Admin User clicks

1. ban user button in
web application.
Application show conformation alert.
2.

and click the button.
Web app successfully blocks the app

4 user.
Post Condition: App user’s account banned successfully.

Alternative Flows:
Priority: High.
14. Delete App User
Use Case ID: UC-14
Use Case name: Delete app user


Use case Description: This use case describes that the admin user deletes app user account the
web application.
Stake Holder and Interests: Admin User want to delete the app user account.
Pre-condition: None
Admin User clicks

1. delete user button
in web
application.
Application show conformation alert.
2.

and click the button.
Web app successfully deletes the app

4 user.
Post Condition: App user’s account deleted successfully.

Alternative Flows:
Priority: High.

CHAPTER 8
UML DIAGRAMS

8.1 UML DIAGRAM

A UML diagram is a diagram based on the UML (Unified Modeling Language) with
the purpose of visually representing a system along with its main actors, roles,
actions, artifacts or classes, in order to better understand, alter, maintain, or document
information about the system.
UML is an acronym that stands for Unified Modeling Language. It is based on
diagrammatic representations of software components. As the old proverb says: “a
picture is worth a thousand words”. By using visual representations, we are able to
better understand possible flaws or errors in software or business processes.
To quote:
“The Unified Modeling Language (UML) is a language for specifying, visualizing,
constructing, and documenting the artifacts of software systems as well as for business
modeling and other non-software systems.”
UML is designed to enable users to develop an expressive, ready to use visual
modeling language. In addition, it supports high level development concepts such as
frameworks, patterns and collaborations. UML includes a collection of elements such
as:
 Programming Language Statements

 Actors: specify a role played by a user or any other system interacting with the
subject.
 Activities: These are tasks, which must take place in order to fulfill an
operation contract. They are represented in activity diagrams.
 Business Process: includes a collection of tasks producing a specific service for
customers and is visualized with a flowchart as a sequence of activities.
 Logical and Reusable Software Components
8.1.1 SEQUENCE DIAGRAM

A sequence diagram is an interaction diagram that shows how processes operate with
one another and in what order. It is a construct of a Message Sequence Chart. A
sequence diagram shows object interactions arranged in time sequence. It depicts the
objects and classes involved in the scenario and the sequence of messages exchanged
between the objects needed to carry out the functionality of the scenario. Sequence
diagrams are typically associated with use case realizations in the Logical View of the
system under development. Sequence diagrams are sometimes called event diagrams,
event scenarios.
A sequence diagram shows, as parallel vertical lines (lifelines), different processes or
objects that live simultaneously, and, as horizontal arrows, the messages exchanged
between them, on order in which they occur.

One of the primaries uses of sequence diagrams is in the transition from requirements
expressed as use cases to the next and more formal level of refinement. Use cases are
often refined into one or more sequence diagrams. In addition to their use in designing
new systems, sequence diagrams can be used to document how objects in an existing
(call it “legacy”) system currently interact.
Diagram building blocks:
If the lifeline is that of an object, it demonstrates a role. Note that leaving the instance
name blank can represent anonymous and unnamed instances.
Messages, written with horizontal arrows with the message name written above them,
display interaction. Solid arrow heads represent. synchronous calls, open arrow heads
represent asynchronous messages, and dashed lines represent reply messages. If a
caller sends a synchronous message, it must wait until the message is done, such as
invoking a subroutine. If a caller sends an asynchronous message, it can continue
processing and doesn’t have to wait for a response. Asynchronous calls are present in
multithreaded applications and in message-oriented middleware. Activation boxes, or
method-call boxes, are opaque rectangles drawn on top of lifelines to represents that
processes are being performed in response to the message.
Objects calling methods on themselves use messages and add new activation boxes on
top of any others to indicates a further level of processing.

8.1.1.1 System Sequence Diagram
Figure 8.1 Sequence Diagram of Automatic College Bell System

8.1.1.2 Sequence Diagram for Login
Figure 8.2 Sequence Diagram of Login

8.1.1.3 Sequence Diagram for Add New Bell Reminder
Figure 8.3 Sequence Diagram of Add new Bell Reminder

8.1.1.4 Sequence Diagram for Connect Bluetooth Device
Figure 8.4 Sequence Diagram of Connect Bluetooth Device
8.1.1.5 Sequence Diagram for View Done Bell Reminders
Figure 8.5 Sequence Diagram of View Done Bell Reminders

8.1.1.6 Sequence Diagram for Hiding Application
Figure 8.6 Sequence Diagram of View Overdue Tasks
8.1.1.7 Sequence Diagram for Today Tasks
Figure 8.7 Sequence Diagram of View Today Tasks

8.1.1.8 Sequence Diagram for Tomorrow Tasks
Figure 8.8 Sequence Diagram of View Tomorrow Tasks
8.1.1.9 Sequence Diagram for Upcoming Tasks
Figure 8.9 Sequence Diagram of View Upcoming Tasks

8.1.1.10 Sequence Diagram for Bell
Figure 8.10 Sequence Diagram for Bell
8.1.1.11Sequence Diagram for Delete Bell
Figure 8.11 Sequence Diagram for Delete Bell

8.1.1.12 Sequence Diagram for Flash Screen
Figure 8.12 Sequence Diagram for Flash Screen

8.2 CLASS DIAGRAM

A class diagram in the Unified Modeling Language (UML) is a type of static structure
diagram that describes the structure of a system by showing the system’s classes, their
attributes, operations (or methods), and the relationships among objects.
The class diagram is the main building block of object-oriented modeling. It is used
both for general conceptual modeling of the systematics of the application, and for
detailed modeling translating the models into programming code. Class diagrams can
also be used for data modeling. The classes in a class diagram represent both the main
objects, interactions in the application and the classes to be programmed.
Classes are represented with boxes which contain three parts:
 The top part contains the name of the class. It is printed in Bold, centered
and the first letter capitalized.
 The middle part contains the attributes of the class. They are left aligned
and the first letter is lower case.
 The bottom part gives the methods or operations the class can take or
undertake. They are also aligned and the first letter is lower case.
In the design of a system, a number of classes are identified and grouped together in a
class diagram which helps to determine the static relations between those objects.
With detailed modeling, the classes of the conceptual design are often split into a
number of subclasses.
8.2.1 Purpose of Class Diagrams
The purpose of class diagram is to model the static view of an application. Class
diagrams are the only diagrams which can be directly mapped with object-oriented
languages and thus widely used at the time of construction.
UML diagrams like activity diagram, sequence diagram can only give the sequence
flow of the application, however class diagram is a bit different. It is the most popular
UML diagram in the coder community.
The purpose of the class diagram can be summarized as −
 Analysis and design of the static view of an application.
 Describe responsibilities of a system.
 Base for component and deployment diagrams.
 Forward and reverse engineering.

8.2.1.1 CLASS DIAGRAM OF SYSTEM
Figure 8.13 Class Diagram of Offline Mobile Finder

CHAPTER 9
SCREENSHOTS

9.1 ANDROID STUDIO CODES

ANDROID MANIFEST
Bell Reminder Activity

Bell Activity
Boot Activity

Calendar Activity
Home Activity

Search Activity
Splash Activity

My Shared Preferences
Reminder Database

Bluetooth
Login

9.2 USER INTERFACE
User Login


User Login Screen
Permission

Automated College Bell System Permission

SPLASH SCREEN
It is a two second screen that appears when the application is opened.

Home Screen
User will see all the reminders here.

Adding Reminder Screen
User on this screen will set the reminder

Details.

All Reminder’s Screen
User will see all the Reminders.

Favorites Reminder’s Screen
User will see favorite Reminders.

Side Menu Screen One
User will see side menu options.

Side Menu Screen Two
User will see side menu options.

Calendar Screen
User will see calendar.

Done Tasks Screen
User will see done tasks here.

Over Due Tasks Screen
User will see Over Due tasks here.

Today Tasks Screen
User will see Today’s tasks here.

Tomorrow Tasks Screen
User will see Tomorrow tasks here.

Upcoming Tasks Screen
User will see Upcoming tasks here

Setting Screen
User can change Setting’s here

Help Screen
User will see Help here

Feedback Screen
User will give feedback here

Ratting Screen
User will rate here

Sharing Screen
User will share here

Bluetooth Screen
User will connect Bluetooth Here

Bell Screen
User will see Bell here

Firebase Home Screen
Admin Home Screen
Firebase Project Settings Screen
Projects Setting Page Admin Side

Firebase Authentication Screen
Admin Authentication Screen
Firebase Realtime Database
Admin Realtime Database Screen

CHAPTER 10
TESTING
QUAID-I-AZAM UNIVERSITY, ISLAMABAD Page |

100
10.1 SOFTWARE TESTING

Software Testing Definition according to ANSI/IEEE 1059 standard – A process of
analyzing a software item to detect the differences between existing and required
conditions (i.e., defects) and to evaluate the features of the software item.
Software testing in an essential phase in the development life cycle of an application.
Testing ensures that the developed system meets its functional and non-functional
requirements. Two important terms in software testing are Verification and
Validation.
 Verification is the process of evaluating work-products like requirement specs,

design specs and test cases etc. of different development phases to make sure
that they meet the requirements for that phase. It ensures that the system is built
in the right way.
Verification: “Are we building the product, right?”
 Whereas Validation is the process of evaluating the software at the end of the
development phase to make sure that it meets the business requirements. It is
used to make sure that the product fulfills its intended use and that the end
product is built right.
Validation: “Are we building the right product?”
In this chapter we mainly validate the app to make sure it meets the requirements set
initially. One of the most important tools to test and debug an Android app is the
Dalvik debug monitor server (DDMS) that is part of the Android framework. DDMS
helps you to debug your code as it prints errors, warning and other information from
your code. It also provides stack traces for exceptions on the Logcat output. Various
other testing strategies have been adopted to make sure the correctness of the app.
There are different types of testing:
 Unit Testing
 Integration Testing
 Regression Testing
 Performance Testing
 System Testing and so on.
Some of them are discussed in this chapter as follows:
10.1.1 Unit Testing

Unit testing is a strategy in software testing where individual components in a
software are tested for correctness. In the apps, these components are the Activities
that are presented to the user as screens on the Android device, Fragments, Services
and Receivers. Below is a list of test cases run on the app, the test cases are
categorized based on the target Activity.

101
10.1.2 Integration testing

Integration testing is a strategy in software testing where different modules are
combined and test to make sure they work together correctly. It is done when the
components are unit test and the main objective is to test the interfaces between
different components.
10.1.3 Performance testing

Performance testing is a type of non-functional testing performed to determine how
fast the system can perform under certain workload. In the app performance testing is
done to make sure that there are no significant lags in the user interface while using
the application due to background tasks etc.
10.1.4 System testing

System testing is testing conducted on a complete integrated system to evaluate the
system's compliance with its specified requirements. System testing takes, as its input,
all of the integrated components that have passed integration testing.
10.2 TEST CASES

A Test Case is a set of conditions or variables under which a tester will determine
whether a system under test satisfies requirements or works correctly. The process of
developing test cases can also help find problems in the requirements or design of an
application
A typical definition for test case is a “set of conditions under which a tester will
determine whether an application or software system or one of its features is working
as expected.”
It means that test cases clarify what needs to be done to test a system. It gives us the
steps which we execute in a system, the input data values which we enter in the
system along with the expected results when we execute a particular test case.
Test cases bring together the whole testing process. If the test cases are ready, they are
really helpful to measure whether client expectations were fulfilled or not.

102
Following are the test cases for all functionalities of the system taken independently.
Post-
S.No Test Case Pre-Condition Result
Condition
1. Phone must have
Android Jelly The
Launch Beans or higher. application
TC-01 Application should launch Pass
2. The application
must be successfully.
installed
properly.
Reminder is
Creating 1. No field should be
TC-02 successfully Pass
New empty.
saved.
Reminder
Reminder
List All
TC-03 1. The application shows shows Pass
Reminders
the list of all reminders are successfully
set. .
Favorite
Creating
TC-04 1. No field should be Reminder is Pass
Favorite
empty. successfully
Reminders
saved.
1. Reminder must be
Playing Bell Played
TC-05 saved in the Pass
Bell Successfully
application.
1. Reminder must be
Reminder saved in the application. Notification
TC-06 Pass
Notification Received
Successfully

103
Post-
S.No Test Case Pre-Condition Result
Condition
1. Reminder must be Reminder

TC-07 Done Tasks shown in the Done Showed Pass
Task screen in Successfully
application.
TC-08 Overdue shown in the Over Showed Pass
Due screen in Successfully
application.
Today
TC-09 shown in the Today Showed Pass
Task
Task screen in Successfully
application.
Reminder
1. Reminder must be
TC-10 Tomorrow Showed Pass
shown in the
Task Successfully
Tomorrow screen in
application.
Reminder
Upcoming 1. Reminder must be Showed Pass
TC-10 shown in the Upcoming Successfully
screen in application.
1. User must provide
correct username and User login
TC-11 User Login password. Pass
Successfully
1. User must provide

User username, name and User
TC-12 password. Registration Pass
Registration
Successfully

104
CHAPTER 11
CONCLUSION
&
FUTURE PROSPECTS

105
11.1 CONCLUSION
The Automatic College Bell System (ACBS) is an essential app to have on a
Smartphone. It is a college bell system and personal to-do reminder app that lets you
have assistance of your daily task and to-do’s in case of non-remembering things.
Furthermore, it is also very helpful in belling and notifying.
The Automatic College Bell System (ACBS) app was our first attempt at an Android
application. It gave us a very good exposure to the Android platform and mobile
development in general. The app enabled me in understanding the basic of Android
development and learning about Android Studio and performance testing of the app.
11.2 FUTURE WORK

The current work on the app has a lot of essential features that would be used in case
of non-remembering like doing class assignment, notifying about class quiz’s play bell
etc. An app for such a purpose has a lot of scope for enhancement. In the future the
app may include features like:
 GPS:
A GPS feature can help the user to automatically add the location of choice.
This feature will help user to add location in the to-do notes to help recognize
or at least remember the location where he/she want to be reminded this feature
will enhance the importance of this app. You can set notes to pop up as
notifications at certain times or places. For instance, you can make your
shopping list note pop up when your GPS indicates that you’re at your local
grocery store.
 Wildcard:
You leave notes on your wallpaper and re-apply it to get your reminders right
on your home screen at all times. It’s a neat way to accomplish the feat without
extra push notifications or a widget. User can create notes over plain
backgrounds or simply write them over your existing wallpaper. Just remember
that this is a wallpaper app, so if you decide you don’t like it, you still have to
switch your wallpaper back to what it was manually.
 Phone Call or Text:

It lets user create tasks with a deadline. The feature simply reminds you when
it’s time to do it. It can even set up phone calls or send SMS/text messages on a
schedule. Tasks are repeatable on a daily, weekly, or monthly schedule, and it
works well.

106
CHAPTER 12
BIBLIOGRAPHY

107
BIBLIOGRAPHY
 https://developer.android.com/
 https://online.visual-paradigm.com/
 https://www.androidauthority.com/
 https://www.oberlo.com/
 https://beebom.com/
 https://www.tutorialspoint.com/android/android_architecture.htm
 https://www.geeksforgeeks.org/android-running-your-first-android-app/
 Pan, Jiantao (Spring 1999). "Software Testing" (coursework). Carnegie
Mellon University. Re trieved September 22, 2021.

108

College LMS: Session: BS Computer Science

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

College LMS: Session: BS Computer Science

Uploaded by

Copyright:

Available Formats

College LMS

Session: BS Computer Science 2019-2023

Supervised By: Mr. Hassan

Project Primary Advisor

QUAID-I-AZAM UNIVERSITY, ISLAMABAD Page | 2

It is to certify that I have read the document meticulously and circumspectly. I

QUAID-I-AZAM UNIVERSITY, ISLAMABAD Page | 3

QUAID-I-AZAM UNIVERSITY, ISLAMABAD Page | 4

College Learning Management System (LMS) is an online college management,

QUAID-I-AZAM UNIVERSITY, ISLAMABAD Page | 5

QUAID-I-AZAM UNIVERSITY, ISLAMABAD Page | 6

QUAID-I-AZAM UNIVERSITY, ISLAMABAD Page | 7

4.3 Requirement Specifications........................................................27

5 Architecture and Design..................................................................29

6 Android Framework Components..................................................33

7 Use Case Diagrams........................................................................... 37

QUAID-I-AZAM UNIVERSITY, ISLAMABAD Page | 8

11 Conclusion and Future Prospects.................................................102

QUAID-I-AZAM UNIVERSITY, ISLAMABAD Page | 9

QUAID-I-AZAM UNIVERSITY, ISLAMABAD Page | 10

 Provide assistance and help scheduling the tasks to the institutes.

QUAID-I-AZAM UNIVERSITY, ISLAMABAD Page | 11

1.4 PROJECT DESCRIPTION

1.5 EXISTING SYSTEMS

QUAID-I-AZAM UNIVERSITY, ISLAMABAD Page | 12

Once you are into BZ reindeer you can do following:

1.5.2 Calendar Notify

 Makes your phone ring, even if left on silent or vibration mode.

Key features include:

 This app helps in setting up the reminders.

QUAID-I-AZAM UNIVERSITY, ISLAMABAD Page | 13

1.6 PROPOSED SYSTEM

Figure 1.1 Lifecycle of System

QUAID-I-AZAM UNIVERSITY, ISLAMABAD Page | 14

QUAID-I-AZAM UNIVERSITY, ISLAMABAD Page | 15

2.2 ANDROID ARCHITECTURE

Figure 2.2 Android Architecture

QUAID-I-AZAM UNIVERSITY, ISLAMABAD Page | 16

2.3 LINUX KERNEL

2.5 ANDROID RUNTIME

2.6 ANDROID FRAMEWORK

QUAID-I-AZAM UNIVERSITY, ISLAMABAD Page | 17

QUAID-I-AZAM UNIVERSITY, ISLAMABAD Page | 18

QUAID-I-AZAM UNIVERSITY, ISLAMABAD Page | 19

QUAID-I-AZAM UNIVERSITY, ISLAMABAD Page | 20

3.1 FEASIBILITY REPORT

A feasibility study should provide management with enough information to decide:

 Whether the project can be done?

3.1.1 Technical Feasibility

QUAID-I-AZAM UNIVERSITY, ISLAMABAD Page | 21

3.1.2 Operational Feasibility

QUAID-I-AZAM UNIVERSITY, ISLAMABAD Page | 22

3.1.3 Economic Feasibility

QUAID-I-AZAM UNIVERSITY, ISLAMABAD Page | 23

QUAID-I-AZAM UNIVERSITY, ISLAMABAD Page | 24

4.1 REQUIREMENT ANALYSIS

4.2 TYPES OF REQUIREMENTS

 Helps you to check whether the application is providing all the

QUAID-I-AZAM UNIVERSITY, ISLAMABAD Page | 25

 The nonfunctional requirements ensure the software system follow legal

4.2.1 FUNCTIONAL REQUIREMENTS

QUAID-I-AZAM UNIVERSITY, ISLAMABAD Page | 26