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

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.

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.

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”

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)

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

‘

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

DAYS REMINDER

SUBJECTS

reminds Scheduled

on

Reminds

on

teaches

T-id name

dept

Location

Branch

Subject

_name

S-id

code

Semester Year

Teacher_

name

description

date R-id

time Day_end code

D-id Day_start

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

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

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:

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.

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.

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()

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

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.

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