The document provides details of a proposed mobile application called "Time Table & Event Reminder App" that allows users to set reminders for events like lectures or meetings. It includes an entity relationship diagram and class diagram that model the database structure, as well as use case, sequence, and collaboration diagrams that describe the interactions between users and the app. The app would allow both students and teachers to view schedules and set reminders for lectures, and also include a general reminder feature for other events.

1. Submitted By: Submitted To:
Pooja Sharma (CS) Mr. Kapil Arora
Anjali (IT) (Asst. Professor)
B.Tech 3rd
year
SRS Documentation
On :
Time Table
&
Event
Reminder App
Session: 2015-16
Semester: 6th

2. ABSTRACT
AIM
In the existing android applications we generally have to set different reminders in the
mobile phone for our schedule. We have to set the reminder again and again. It is a very
time consuming task for someone who has a fixed schedule a specific time. He/she has to
set the reminder every time.
The application developed by us can remind us of any event/task we mark on it. It reminds
us about lectures, meeting, time to pay bill etc. The application can take from user the
event, name, date and time of event. Store the details to the database and alert the user n
minutes before the event. Application will be used as a “reminder” for specific type of
event. It has the ability to save multiple events. Events are based on alternating calendar
dates and frequency (user input). All the information stored is classified depending on how
it relates to time. Reminders are piece of information tightly bound to a specific time. For
example if you have a meeting on Monday at 11 A.M. then you should setup a reminder to
allow you to do the work in timely fashion.
Whether you are a home user, student or professional it is always important to keep and
organize important information, date and events. In this application we mainly focus on
managing the time table of the college where teacher can get the alert of his/her lecture
schedule n minutes prior the start and end of the lecture. Also there is an additional
application for a general reminder that can be set by user. Our application that falls into
this category is the Event Reminder and Scheduler Application developed for the Google
Android Phones.
In our application a person need not set a reminder every time for a fixed schedule. It has
been basically designed for a periodic series of events such as time table schedule for the
teachers as well as students. A database is stored for a particular time table which includes
the name of the faculty member teaching the subject, the venue of the subject and the time
of the lecture for the subject including the duration of the lecture.
Apart from the time table reminder a general reminder can also be set by the user for
general purposes. The application is divided into two categories by General Reminder and
Time Table Reminder. The user can decide which reminder to use according to his/her
requirement.

3. ADVANTAGES
 Enables quick management of lectures timings & venue for both, the teachers &
students.
 Need not set the reminder repeatedly every time for each day.
 Stores the subject information like subject code, teacher’s name, subject name,
venue & schedule for the whole week.
 Quick adding, deleting & updating of the subjects & events
 Also helps to set the general reminders as that of the meetings & the other tasks.
 Gives the summarized view of the time table of the week & the description of the
event to plan the timely schedule.
 User friendly & quick to use interface.
DISADVANTAGES
 Can only be used on the platform supporting Android OS.
 Cannot be used in non-smartphone or non-tablet hardware environment & platform.
PROPOSED SYSTEM
Event Reminder and Scheduler Application is software developed for reminding about
lectures in schools, colleges and institutes and can be used by students as well as teachers.
In addition, it also includes facility to set reminder for any event.
The proposed system is as described below:
 To provide the faculty members as well as the students to keep track of the lectures
to be conducted including their venue.
 To create a database in the system that automatically keeps track of lectures in a
systematic and efficient way.
 To serve the purpose of both general and timetable reminder in one as the user need
not open a separate application for different types of reminders.
 To provide a graphical user interface that is easy and interactive to use.
 To provide the summarized view of timetable in tabular form & description of the
events.

4. SYSTEM REQUIREMENTS
HARDWARE REQUIRED
 The absolute minimum requirement for Android were originally a 200 MHz
processor, 32 MB of RAM, and 32 MB of storage.
 For the base SDK package, at least 600MB of available disk space. For each
platform downloaded into the SDK, an additional 00 MB is needed.
 Out of box, Android is incompatible with ARMv4 or lower: ARMv5 or higher is
needed to run native code without modifications.
 Android 4+ requires an ARMv7 processor. Custom version of Android 4+ have
been made for ARMv6 however.
SOFTWARE REQUIRED
Start with the Android compatibility page. This outlines goals for Android’s compatibility
and links to the current Compatibility Definition Document which has the technical
requirements.
All versions of the CDD to date are below.
 Android 5.0 ”Lollipop”
 Android 4.4 “KitKat”
 Android 4.3, Android 4.2 and Android 4.1 “Jelly Bean”
 Android 4.0 “Ice Cream Sandwich”
 Android 3.0 “Honeycomb” not available (since it was not a public open-source
release)
 Android 2.3 “Gingerbread”
 Android 2.2 “Froyo”

5.  Android 2.1 “Eclair”
 Android 1.6“Donut”
Supported Development Environments
 Eclipse IDE
o Eclipse 3.4 (Ganymede) or 3.5 (Galileo)
o Eclipse JDT plugin (included in most Eclipse IDE packages)
o JDK 5 or JDK 6( JRE alone is not sufficient)
o Android Development Tools plug-in(optional)
o Not compatible with Gnu Compiler for JAVA (GCJ)
 Other development environment or IDEs
o JDK 5 or JDK 6 (JRE alone is not sufficient)
o Apache Ant 1.6.5 or later for Linux and Mac,1.7 or later for windows
o Not compatible with Gnu Compiler for JAVA(GCJ)

6. ENTITY-RELATIONSHIP MODEL
In software engineering, an entity–relationship model (ER model) is a data model for describing
the data or information aspects of a business domain or its process requirements, in an abstract
way that lends itself to ultimately being implemented in a database such as a relational database.
The main components of ER models are entities (things) and the relationships that can exist among
them.
Entity–relationship modeling was developed by Peter Chen and published in a 1976 paper.
However, variants of the idea existed previously, and have been devised subsequently such as
super type and subtype data entities and commonality relationships.
It is used for the database design process by following the specification of enterprise schema. It
represents the overall logical structure of database, consisting of set of objects called the entities
& the relationship among those entities. The basic notation of ER models are-
1. Entity- It is the thing or object in the real-world that is distinguishable from all other object. An
entity has a set of properties & values, some set of properties may uniquely identify an entity in an
entity set.
2. Attributes- An entity is represented by set of attributes that is properties of an entity. Attributes
define the characteristic of an entity. It is also referred to as data item or data field. Attributes are
further classified as- simple, composite, single-value, multi-value, derived & descriptive.
3. Relationship- It is an association among the several entities.
The symbols used in the ER diagram-
Link Total participation
Entity Attribute
Multivalue attribute
Primary key Derived Attribute Relationship
Weak relation

7. ‘
The app has 4 entities namely- Teacher, Subjects, Reminder & Days. The relationship
between these entities is as shown in the figure above along with the attributes the each
entity possess. This ER model reflects the database schema where the entities denote the
table names & their attributes denote the fields in each table. The relationships are as
explained:
1. Teacher/Student adds the subject information of those subject which he teaches/are
taught in the Subject Table & his own information in the Teacher table
2. The subjects scheduled on which days are added in the Days table.
3. The Teacher/student activates the reminder.
4. The reminder is activated on the time provided by Days table on the particular day.
TEACHER
DAYSREMINDER
SUBJECTS
reminds Scheduled
on
Reminds
on
teaches
T-id
name
dept
Location
Branch
Subject
_name
S-id
code
SemesterYear
Teacher_
name
description
dateR-id
time Day_endcode
D-id Day_start

8. CONTEXT-FREE DIAGRAM
The Context diagram is a simple model that define the boundary & the interface of the
proposed system. It identifies the entities of the proposed system that interact with the
system. This is high level view of system & similar to the block diagram of the system.
The context diagram are also termed as the 0-level DFDs including the Input provided to
the system & the output which will be derived after processing by the system.
The Context-Free diagram for the App is as given below:
In the above given Context free diagram-
1. The inputs are the lecture timings, subject information, Teacher’s information or the
other events information for the time table & the general reminder respectively which will
be saved in the database & fetched from there on the user interface on the app.
2. The outputs of the system will be:
 Time table reminder activated & buzz for each subject on time in the week.
 The general reminder buzzed & activated on the scheduled time.
 Summarized view of the time table for the week & the day on the basis of set criteria.
Also the event description of the general reminders can also be viewed.
Time Table &
Event
Reminder
Lecture
timings,
subject info
General
Reminder &
schedule
Summarize
d Time
table
Daily
reminder
individually
of lecture
Other
events info

9. USE CASE DIAGRAM
A use case diagram at its simplest is a representation of a user's interaction with the system
that shows the relationship between the user and the different use cases in which the user
is involved.
Use case diagram visually represent what happens when an actor interact with the system.
The system is shown as rectangle with the name of a system or sub-system inside. The
actor is shown as the stick figure, the use case are shown as ovals labelled with the name
of use cases & the relationship are the lines or arrow between the actors & the use cases
&/or between the use cases itself. Actors appear outside the rectangle since they are
external to the system, use cases appear within the rectangle providing the functionality. A
relationship is the solid line between the actor & each use case in which actor participate,
the involvement can be any kind.
The use case diagram for the App is as given below:
In this use case diagram,
 The actors are the students as well as the teachers.
 The use cases or processes are The Time Table Reminder, The General Reminder
& the View Summary Schedule.
 The Summary Schedule is derived from the Time Table Reminder information as
well as the General Reminder fed information.
 The actors can access all the processes of the system.
 The whole system is termed as the Time Table & Event Reminder App.
Time Table
Reminder
General
Reminder
View Schedule
Summary
User
(Students +
Teachers)
Time Table & Event
Reminder App

10. DATA FLOW DIAGRAM
A data flow diagram (DFD) is a graphical representation of the "flow" of data through an
information system, modelling its process aspects. A DFD is often used as a preliminary
step to create an overview of the system, which can later be elaborated. DFDs can also be
used for the visualization of data processing (structured design).
A DFD shows what kind of information will be input to and output from the system, where
the data will come from and go to, and where the data will be stored. It does not show
information about the timing of process or information about whether processes will
operate in sequence or in parallel (which is shown on a flowchart).
DFDs are widely used for modelling & the requirement. DFD shows a flow of data through
a system. The system may be a company, organization, set of procedure, software system
or any combination of the preceding. A DFD explain how the data is processed by a system
in terms of input & output. As it indicates, it focus on the flow of the information, where
data comes from, where it goes & how it get started. It is graphical representation which
provide the information flow & the transformation between the input & output data. It is
also known as data flow or the bubble chart. The purpose of DFD is:
1) It provide the indication how data is transformed.
2) It shows the function or sub-function which transform the data flow.
Symbols used for constructing the DFD are-
1) Function Symbol or the process- A function is represented by using the circle. This
symbol is called a process or bubble & perform some processing of input data.
2) Data flow Symbol- A directed edge or an arrow is used as a data flow symbol. A data
flow symbols represent the data flow occurring between the 2 processes or between an
entity or source & the process.
3) Data store symbol- This is used to store the data. It may be entire database or everything
that may store data that is file.
4) Sources or Sink- The function of source or sink is a source of a system inputs or the
sink of a system output. It is an external entity acts a source of system input or sink of
system output.
The 0-level DFD of a system is equivalent to the context-free diagram which has been
explained above. The 1- level DFD of the App is as given below:

11. TIME-TABLE
REMINDER
GENERAL
REMINDER
USER
(Teacher+
Student)
VIEW
Summary
TEACHERS INFO INFORMATION
DAYS & SUBJECT
INFO
DATABASE
TIME
TIME+DATE INFORMATION
SCHEDULE
INFORMATION
In this DFD:
 The process Time Table & Event Reminder is sub-divided into 3 main processes-
Time Table Reminder, General Reminder & View Summary.
 The User can add Teacher’s information, Days information, subject Information &
time in the process along with deletion & update function too. All this information
will be saved in the database.
 The General Reminder will take schedule, event description, date & time as the
input from the user. This information will also be saved in the database.
 The View Summary process will fetch the information stored in the database based
on some criteria & display it back to the user as the summarized time table or event
detail.

12. 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 or 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, in the order in which they occur. This allows the specification of simple
runtime scenarios in a graphical manner.
If the lifeline is that of an object, it demonstrates a role. 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.[1]
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.
Objects calling methods on themselves use messages and add new activation boxes on top
of any others to indicate a further level of processing. A message sent from outside the
diagram can be represented by a message originating from a filled-in circle or from a border
of the sequence diagram.
In the below given sequence diagram,
 The User creates the new entry for the reminder information
 Adds the Subject or event. He/she may also delete & update the existing recorded
entry.
 The Information manipulation (add, delete & update) by the user are saved into the
database.
 This information is returned to the Time Table & Event schedule process by the
database.
 The user can then activate the reminder.

13. Create()
Add()
Activate() Update() Save()
Delete()
Return View()
USER Summary
Subject or Event
Time Table & Event
Schedule
 The Summary process is invoked to view the summarized information of the time
table or the event as added by the user.
 The Summarized information is returned to the user in return of this invoke.
The sequence diagram for the app is as given below:
Show()

14. COLLABORATION DIAGRAM
A collaboration diagram, also called a communication diagram or interaction diagram, is
an illustration of the relationships and interactions among software objects in the Unified
Modeling Language (UML). The concept is more than a decade old although it has been
refined as modeling paradigms have evolved.
A collaboration diagram resembles a flowchart that portrays the roles, functionality and
behavior of individual objects as well as the overall operation of the system in real time.
Objects are shown as rectangles with naming labels inside. These labels are preceded by
colons and may be underlined. The relationships between the objects are shown as lines
connecting the rectangles. The messages between objects are shown as arrows connecting
the relevant rectangles along with labels that define the message sequencing.
Collaboration diagrams are best suited to the portrayal of simple interactions among
relatively small numbers of objects. As the number of objects and messages grows, a
collaboration diagram can become difficult to read. Several vendors offer software for
creating and editing collaboration diagrams.
The collaboration diagram for the App is as given below:
6. Delete()
2. Add()
5. Update()
6.
3. Save()
3. Save()
5. Update()
6.6. Delete()
2. Add()
4. Activate() 1. Create()
8. Show()
3. Save()
7. View()
1. Create()
4. Activate()
Start
Subject time, day
teacher, code, etc.
Time Table
Reminder
User
Database
General reminder
Database
Time table & event
summary
Event info & time

15. In this collaboration diagram,
 Once the user starts using the App, he/she may choose any one of the three options-
Time Table Reminder, General Reminder or The Summary
 The functions for The Time Table & The General Reminder are described as below:
1. Create()- Create a new reminder entry.
2. Add()- Add the reminder details like description, timing, days, etc.
3. Save()- Save the added entry into the database.
4. Activate()- Activate the reminder whenever to use.
5. Update()- Update the existing reminder information
6. Delete()- Delete the existing reminder
 The functions for the summary are as below:
7. View()- The command to view the summarized time table or the event
description.
8. Show()- The summarized information is returned to the user.

16. INDEX
1) Abstract 2-3
 Aim
 Advantages
 Disadvantages
 Proposed System
2) System Requirements 4-5
 Hardware Required
 Software Required
3) Entity-Relationship Diagram 6-7
4) Context-Free Diagram 8
5) Use-Case Diagram 9
6) Data Flow Diagram 10-11
7) Sequence Diagram 12-13
8) Collaboration Diagram 14-15