Visit Bangladesh SRS
Visit Bangladesh SRS
Visit Bangladesh SRS
SPL-2
Software Requirement
Specification and Analysis
Visit Bangladesh
An Android App
Course: SE 505
Submitted by
Supervised by
Sumon Ahmed
Assistant Professor
Date: 16/03/202
Acknowledgement
We are highly indebted for getting such a wonderful opportunity to prepare the
Software Requirements Specifications report of the project ‘Visit Bangladesh’. We
would like to thank whole-heartedly our supervisor, Sumon Ahmed, Assistant
Professor, Institute of Information Technology, University of Dhaka, our teacher,
Nadia Nahar, Lecturer, for giving us guidelines on preparing this report.
Abstract
1
Table of Contents
Chapter 1: Introduction 7
1.1 Purpose 7
1.2 Intended Audience 7
1.3 Conclusion 8
Chapter 2: Inception 9
2.1 Introduction 9
2.1.1 Identifying Stakeholders 11
2.1.2 Recognizing Multiple Viewpoints 12
2.1.3 Working towards collaboration 13
2.1.4 Asking the First Questions 15
2.2 Conclusion 15
Chapter 3: Elicitation 16
3.1 Introduction 16
3.2 Eliciting Requirements 16
3.2.1 Collaborative Requirements Gathering 17
3.2.2 Quality Function Deployment 17
3.4.2.1 Normal Requirements 18
3.4.2.2 Expected Requirements 19
3.4.2.3 Exciting requirements 20
3.2.3 Usage scenario 21
Chapter 4: Scenario Based Modeling 25
4.1 Introduction 25
4.2 Use Case Scenario 25
4.3 Use Case Descriptions 26
4.3.1 Authentication 26
2
4.3.2 Browse 28
4.3.3 Navigation 30
4.3.4 Geo-fencing 33
4.4 Use Case Diagrams 37
4.5 Activity Diagrams and Swimlane Diagrams for generated Use Cases 40
Chapter 5: Data Modeling 68
5.1 Data modeling concept 68
5.2 Data objects 68
Chapter 6: Class Based Modeling 78
6.1 Class Based Modeling Concept 78
6.2 General Classification 78
6.3 Selection Criteria 81
6.4 Associate Noun and Verb Identification 82
6.5 Attribute Selection 83
6.6 Methods Identification 84
6.7 Finalizing Classes 85
6.8 Class Cards 86
6.8 UML Diagram 91
Chapter 7: Flow-Oriented Model 92
7.1 Introduction 92
7.2 Data Flow Diagram (DFD) 92
Chapter 8: Behavioral Model 98
8.1 State Diagram 98
8.2 Sequence Diagram 105
3
Table of Figures
Figure 1: Level 0 for Visit Bangladesh............................................................................................32
Figure 2: Level 1 for Visit Bangladesh............................................................................................33
Figure 3: Level 1.1 for Visit Bangladesh.........................................................................................34
Figure 4: Level 1.1.1 for Visit Bangladesh......................................................................................34
Figure 5: Level 1.2 for Visit Bangladesh.........................................................................................35
Figure 6: Level 1.3 for Visit Bangladesh.........................................................................................35
Figure 7: Level 1.3.1 for Visit Bangladesh......................................................................................36
Figure 8: Level 1.4 for Visit Bangladesh.........................................................................................36
Figure 9: Level 1.5 for Visit Bangladesh.........................................................................................37
Figure 10: Level 1.5.1 for Visit Bangladesh....................................................................................37
Figure 11: Level 1.6 for Visit Bangladesh.......................................................................................38
Figure 12: Activity diagram for Sign In..........................................................................................39
Figure 13: Swimlane diagram for Sign In........................................................................................40
Figure 14: Activity diagram for Register.........................................................................................41
Figure 15: Swimlane diagram for Register......................................................................................42
Figure 16: Activity diagram for Guest User.....................................................................................43
Figure 17: Swimlane diagram for Guest User..................................................................................44
Figure 13: Activity diagram for Browse Map..................................................................................46
Figure 14: Swimlane diagram for Browse Map................................................................................47
Figure 15: Activity diagram for Search Place..................................................................................48
Figure 16: Swimlane diagram for Search Place................................................................................49
Figure 17: Activity diagram for Show Details..................................................................................50
Figure 18: Swimlane diagram for Show Details...............................................................................51
Figure 19: Activity diagram for Set Direction Aid............................................................................52
Figure 20: Swimlane diagram for Set Direction Aid.........................................................................53
Figure 21: Activity diagram for Send Direction Aid.........................................................................54
Figure 22: Swimlane diagram for Send Direction Aid.......................................................................55
Figure 23: Activity diagram for Edit Direction Aid..........................................................................56
Figure 24: Swimlane diagram for Edit Direction Aid........................................................................57
Figure 25: Activity diagram for Update position..............................................................................58
4
Figure 26: Swimlane diagram for Update position............................................................................59
Figure 27: Activity diagram for Set Parental Control........................................................................60
Figure 28: Swimlane diagram for Set Parental Control.....................................................................61
Figure 29: Activity diagram for Edit Parental Control.......................................................................62
Figure 30: Swimlane diagram for Edit Parental Control....................................................................63
Figure 31: Activity diagram for Restrict Area..................................................................................64
Figure 32: Swimlane diagram for Restrict Area...............................................................................65
Figure 33: Activity diagram for Edit Restrict Area...........................................................................66
Figure 34: Swimlane diagram for Edit Restrict Area.........................................................................67
Figure 35: Entity Relationship diagram for E-Shongee.....................................................................72
Figure 36: UML diagram for E-Shongee.........................................................................................91
Figure 37: Level 0 DFD diagram for E-Shongee..............................................................................92
Figure 38: Level 1 DFD diagram for E-Shongee..............................................................................93
Figure 39: Level 2.1 DFD diagram for E-Shongee...........................................................................94
Figure 40: Level 2.2 DFD diagram for E-Shongee...........................................................................95
Figure 41: Level 2.3 DFD diagram for E-Shongee...........................................................................96
Figure 42: Level 2.4 DFD diagram for E-Shongee...........................................................................97
Figure 43: Database Class State Diagram for E-Shongee..................................................................98
Figure 44: Geofence Class State Diagram for E-Shongee..................................................................99
Figure 45: Map Class State Diagram for E-Shongee.......................................................................100
Figure 46: Notification Class State Diagram for E-Shongee............................................................101
Figure 47: Route Class State Diagram for E-Shongee.....................................................................102
Figure 48: System Class State Diagram for E-Shongee...................................................................103
Figure 49: Waypoint Class State Diagram for E-Shongee...............................................................104
Figure 50: Sequence diagram (Sign In).........................................................................................105
Figure 51: Sequence diagram (Sign Up)........................................................................................106
Figure 52: Sequence diagram (Manage Account)...........................................................................107
Figure 53: Sequence diagram (Browse Map).................................................................................108
Figure 54: Sequence diagram (Search Place and Show Details).......................................................109
Figure 55: Sequence diagram (Set Direction Aid)..........................................................................110
Figure 56: Sequence diagram (Edit Direction Aid).........................................................................111
Figure 57: Sequence diagram (Send Direction Aid)........................................................................112
Figure 58: Sequence diagram (Set Parental Control).......................................................................113
Figure 59: Sequence diagram (Edit Parental Control).....................................................................114
Figure 60: Sequence diagram (Restrict Area).................................................................................115
Figure 61: Sequence diagram (Edit Restrict Area)..........................................................................116
5
List of Tables
Table 1: Noun Identification.......................................................................................................... 60
Table 2: Final Data objects............................................................................................................ 61
Table 3: Relational Schema (User).................................................................................................63
Table 4: Relational Schema (Place)................................................................................................63
Table 5: Relational Schema (User Searches Place)...........................................................................64
Table 6: Relational Schema (User Notifies User).............................................................................64
Table 7: Relational Schema (Route)...............................................................................................65
Table 8: Relational Schema (User Follows Route)...........................................................................65
Table 9: Relational Schema (User Shares Route).............................................................................66
Table 10: Relational Schema (Route Contains Waypoints)................................................................67
Table 11: Relational Schema (User creates Geo-fence).....................................................................67
Table 12: Noun of General Classification........................................................................................70
Table 13: Potential Classes............................................................................................................ 71
Table 14: Associate Noun and Verb...............................................................................................72
Table 15: Attribute Selection......................................................................................................... 73
Table 16: Method Identification.....................................................................................................75
Table 17: Class Card (User)........................................................................................................... 76
Table 18: Class Card (System).......................................................................................................77
Table 19: Class Card (Database)....................................................................................................77
Table 20: Class Card (Map)........................................................................................................... 78
Table 21: Class Card (Route).........................................................................................................78
Table 22: Class Card (Waypoint)...................................................................................................79
Table 23: Class Card (Geo-fence)..................................................................................................79
Table 24: Class Card (Notification)................................................................................................80
6
Chapter 1: Introduction
This chapter is a part of Software Project Lab-2(SPL-2), intended to specify the
purpose of this document and the intended audience of it.
1.1 Purpose
7
This SRS is intended for several audiences, including the customers, as well as the
project managers, designers, developers, and testers.
● The customer will use this SRS to verify that the developer team has created a
product that is acceptable to the customer.
● The project managers of the developer team will use this SRS to plan milestones
and a delivery date, and ensure that the developing team is on track during
development of the system.
● The designers will use this SRS as a basis for creating the system’s design. The
designers will continually refer back to this SRS to ensure that the system they are
designing will fulfill the customer’s needs.
● The developers will use this SRS as a basis for developing the system’s
functionality. The developers will link the requirements defined in this SRS to the
software they create to ensure that they have created software that will fulfill all of
the customer’s documented requirements.
● The testers will use this SRS to derive test plans and test cases for each
documented requirement. When portions of the software are complete, the testers
will run their tests on that software to ensure that the software fulfills the
requirements documented in this SRS. The testers will again run their tests on the
entire system when it is complete and ensure that all requirements documented in
this SRS have been fulfilled.
8
1.3 Conclusion
This analysis of the audience helped us to focus on the users who will be using our
analysis. This overall document will help each and every person related to this
project to have a better idea about the project.
Chapter 2: Inception
In this chapter, the Inception part of the SRS will be discussed briefly.
9
2.1 Introduction
➢ Identifying Stakeholders
10
2.1.1 Identifying Stakeholders
Stakeholder refers to any person or group who will be affected by the system
directly or indirectly. Stakeholders include end-users who interact with the system
and everyone else in an organization that may be affected by its installation. At
inception, a list of people who will contribute input as requirements are elicited.
The initial list will grow as stakeholders are contacted because every stakeholder
will be asked: “whom else do you think I should talk to?”
11
2.1.2 Recognizing Multiple Viewpoints
Different stakeholders demand different features from the software. To satisfy the
stakeholders, most of these features should be included in the software.
Customers’ viewpoint
● Supply user with appropriate route from source address to destination address
Developer’s viewpoint
● Easy to built
● No conflicting requirement
12
● Getting maximum experience from development
While working with different customers, some conflicting and common viewpoints
can be noticed. For this reason, final requirements can be obtained by collaborating
the viewpoints. We followed following steps to merge these requirements:
Take priority points for each requirements from customers and on the basis of this
voting prioritize the requirements
Common Requirements:
13
Maintain a database for all users and all locations in the system
Conflicting Requirements:
Final Requirements:
Restrict access to functionality of the system based upon user roles. For example,
only users with parental control over other user can set restrictions for places and
not the other way around.
14
2.1.4 Asking the First Questions
We set our first set of context-free questions focuses on the customer, overall
project goals and benefits. The questions are mentioned above. These questions
helped us to identify all customers, measurable benefit of the successful
implementation and possible alternatives to custom software development. Next
set of question helped us to gain a better understanding of problem and allows the
customer to voice his or her perception about the solution. The final set of question
focused on the effectiveness of the communication activity itself.
2.2 Conclusion
Chapter 3: Elicitation
15
This chapter specifies the Elicitation phase.
3.1 Introduction
The main task of this phase is to combine the elements of problem solving,
elaboration, negotiation and specification. The collaborative working approach of
the stakeholders is required to elicit the requirements. The following tasks were
done for eliciting requirements:
16
3.2.1 Collaborative Requirements Gathering
● The meetings were conducted with a few customers, questioned about their
requirements and expectations from E-Shongee
● The customers were asked which requirements should be added to the
application
● At last we selected our final requirements from the discussions
Quality Function Deployment (QFD) is a technique that translates the needs of the
customer into technical requirements for software. It concentrates on maximizing
customer satisfaction from the Software engineering process. With respect to our
project the following requirements are identified by a QFD.
17
3.4.2.1 Normal Requirements
The normal requirements are generally the objectives and goals that are stated for a
product or system during meetings with the customer. The presence of these
requirements fulfills customers’ satisfaction. These are the normal requirements for
the project.
Android application
Accessible via the Internet.
Allow any user to search for places.
Allow Administrators to check user information(not personal)
Allow valid users to login and logout
Restrict access to functionality of the system based upon user roles
Allow valid users that log in to navigate the map
Getting information about preferred locations and search strings
The server only needs to be maintained on one computer.
User manual and guidelines
Storing information regarding favorite places
Storing profit records for autosuggestions
Using limited budget for making the software
Keeping track of restricted areas
Storing accurate records of transactions
Identifying restricted locations
Contacting users in times of danger
Calculating distance between source and destination
18
3.4.2.2 Expected Requirements
19
3.4.2.3 Exciting requirements
These requirements are for features that go beyond the customer's expectations and
prove to be very satisfying when present
The user interface should provide appropriate error messages for invalid
input as well as tool-tips and guidelines
The user interface should follow standard android application interface
practices such as navigation bars search panels etc.
Offer log in with mobile phone number after sending verification code to
number
Confirming parental supervision by generating code
Autosuggestion of places based on country
Change view of map
Change mode of navigation
Add audio based aid in routing
Send navigation route to other users after establishing proper connection\
Users can modify the route and shared routes will be updated after
confirming modification
System sends notification to users informing current situation of friends and
family
Alerts user when getting closer to destination
20
3.2.3 Usage scenario
Authentication
Sign Up:
Sign in:
If any user has an account, he/she can sign in to the system. To sign in, user
has to give his/her mobile number and enter the verification code that will be
sent to the number. The mobile number and code will be verified. If the
verification is successful, the user can sign in to the system successfully. If the
code/number is wrong, there is a retry option.
21
Sign Out:
User has an option to log out from the system. The phone number associated
with the user will be displayed on the login application interface.
Manage Account:
Any user can change their information. To change information, he/she has to sign in then change
information. He/she has to confirm the changes and the changes will be confirmed.
Browse
Browse Map:
When the user logs in to the android application then a map will be loaded. If location and gps
permissions are not enabled then the application would require user approval for gps services.
The current location of the user will be displayed on the map and the user can swipe the map to
view adjacent places. The user can zoom on/zoom out the map to provide more detail about the
area.
Search Place:
There must be a search bar to search for locations with the name of the places and the data will
be retrieved from the database of place having a unique place_id. The location could be a
specific shop or an area. The search panel will provide auto suggestions of places in Bangladesh.
The system will keep a cache of user’s choice ad make a list of recommended from previous
searches. If user wants to see, system can show a list of recommended location for him/her. After
the search has been completed and a place is selected, the camera will move to the specified
place.
Place Detail:
If the user selects a specific place and wants to know details about the place then the system
will provide with information about the place such as place-type, latitude, longitude etc.
22
Navigation
Update Position:
When a user changes his/her location then it is tracked by the gps system of the android device
and the application gets notified about the change in position. The marker of current location is
also changed based on the actual location of the user. There must be internet availability for the
gps system to track the user. This procedure is also applicable during navigation from source to
destination. If direction is set by other user then after getting close to the destination, the sender
will get informed continuously with approximate time for arrival.
When the user selects a destination address and wishes to get directions to the address, then a
route will be generated from the user’s current location to that specified destination. The routing
information made by the user will be stored in the database with a route_id. The user can also
change the source address and then generate the route for the selected source and destination
address. The users can also modify the way points in the route by selecting a specific waypoint
and can also add multimedia such as audio aid for a specific waypoint.
After setting the direction aid, the user can send the navigation aid to other users via phone
number. This route with multimedia aid will be shown in the receiving side if the user wishes to
accept the coming routing information.
Once the direction is obtained from source to destination, it can be modified using voice aided
information. Even after the data is sent to other users it can be modified by the user who made
the direction aid. One the modification of navigation information is completed, the user will
confirm the change and the change will be updated to other users who are concerned. And the
receiving side will be notified about the change.
23
Geo-fencing
A user can set restriction in areas to visit to other users only after following some procedures.
After a user sends request for parental control using phone number of other users. Then a
confirmation code generated by other user will be required for the confirmation of the process.
The code generated will be unique for each user. The user can have parental control over various
users. Appropriate notification will be sent to each of the users with a notification_id.
A user can modify the list of parents i.e. can remove or add new users to allow restriction and
monitoring. Information of user will be sent to the listed users accordingly. If a user wishes to
remove a user as parent, then notification will be send to the other user. This process will be
completely effective only after confirming the actions.
Restrict Area:
A user can set restriction in areas to visit to other users if and only if the user has parental
control over the intended user. The user can set the restriction area in two ways-
1. Placing markers to draw polygon
2. Selecting center and radius on the map to draw circle
The restriction can work in both ways which will be determined by the parent user. One of the
ways would be determining the inner fence and the other would be the outer fence. If the user
enters/leaves the restricted area then the parental user responsible for that particular restriction
will be alarmed. The fence will have a geofence_id for each.
Edit Restrictions:
A user can see the restrictions set by other users. First the user can see all the restrictions set
by various users in the map. On the hand, the user can select specific parental user and see the
restrictions set by that user on the map. He/she can also request for a restriction to be removed to
the parental users and thus appropriate notifications will be sent. If the parent agrees then that
particular restriction will no longer be valid and will not be valid to the user.
24
Chapter 4: Scenario Based Modeling
4.1 Introduction
In this model the system is described from the user’s point of view. As this is the
first model, it serves as input for creation of other modeling elements.
Register
Authentication
Guest User
Add image
Update
Add new places Add details
Visit Bangladesh
Add comments
Add route
Search by State/Division
Change profile
picture
Settings Edit Account
Reset Username
Emergency
Add contact
Contact
Send notification
25
4.3 Use Case Descriptions
4.3.1 Authentication
4.3.1.1 Register
Preconditions:
1. System has been designed for Sign up
2. System has interface for Sign
up
Scenario:
1. Run app and sign up
2. Provided phone number
3. Check availability of phone number
4. Verify information
5. Send verification code
6. Match input verification code
7. Provide required information
Exception:
1. Same phone number
2. Mismatched verification code
3. Time limit exceeded
4.3.1.2 Log In
Use Case: Log In
26
Primary Actor: User, Admin
Preconditions:
1. System has been designed for login
2. System has interface for login
Scenario:
1. Visit page and login
2. Provide the required information
3. Proceed to App Interface
Exception:
1. Unrecognized phone number
2. Wrong verification code
Preconditions:
1. System has been designed for Guest user
2. This type of user cannot access all section of app
3. This type of user do not need to login
Scenario:
1. Can view tourist places
Exception:
1. User not logged in
27
4.3.2 Browse
Preconditions:
1. System has been designed for viewing images of places
2. System has interface for browsing
3. Has list of images
Scenario:
1. Complete Login/Guest User
2. Provide route
3. Load images based on places
Exception:
1. Collection of images
Preconditions:
1. System has been designed for making tourist to convey knowledge
2. System has interface for names and facts of places
28
Scenario:
1. View interesting information
Exception:
1. Invalid facts
4.3.2.3 Route
Use Case: Way to reach destination
Preconditions:
1. System has been designed for viewing the route to tourist place
Scenario:
1. Users have to navigate to a place
Exception:
1. Place not selected properly
4.3.3 Update
Goal in context: Enable local people to add exciting places in their locality
Preconditions:
29
1. System has been designed for making application working on large scale
2. System has interface for adding new places
Scenario:
1. Approved user can directly add new place
Preconditions:
1. System has been designed for finding routes
2. System has interface for showing routes
Scenario:
1. Press the add directions button
2. Define mode of navigation like driving, walking, etc.
Exception:
1. Source/destination not found
2. Direction not available
4.3.4 Search
30
4.3.4.1 Search by Division/State
Preconditions:
1. System has been designed for easy search
Scenario:
1. User can enter state name on navigation pane
Exception:
1. Invalid state name
Preconditions:
1. System has been designed for modifying search operation
Triggers: Customer wants to modify search option
Scenario:
1. User can enter place name on navigation pane
Exception:
2. Invalid and unfamiliar place name
31
4.3.5 Setting
4.3.5.1 Edit Account
4.3.5.1.1 Change profile images
4.3.5.1.2 Reset Username/password
32
Figure 2: Level 1 for Visit Bangladesh
33
Figure 3: Level 1.1 for Visit Bangladesh
34
Figure 5: Level 1.2 for Visit Bangladesh
35
Figure 7: Level 1.3.1 for Visit Bangladesh
36
Figure 9: Level 1.5 for Visit Bangladesh
37
Figure 11: Level 1.6 for Visit Bangladesh
38
4.5 Activity Diagrams and Swimlane Diagrams
39
Swimlane Diagram:
40
4.5.2 Use Case 2: Register
Activity Diagram:
41
Figure 14: Activity diagram for Register
Swimlane Diagram:
42
Figure 15: Swimlane diagram for Register
43
4.5.3 Use Case 3: Guest User
Activity Diagram:
44
Swimlane Diagram:
45
4.5.4 Use Case 4: Browse
Activity Diagram:
46
Swimlane Diagram:
47
4.5.5 Use Case 5: Update
Activity Diagram:
48
Swimlane Diagram:
49
4.5.6 Use Case 6: Search
Activity Diagram:
50
Swimlane Diagram:
51
4.5.7 Use Case 7: Setting
Activity Diagram:
52
Swimlane Diagram:
54
Swimlane Diagram:
55
Chapter 5: Data Modeling
If software requirements include the necessity to create, extend or interact with a database or
complex data structures need to be constructed and manipulated, then the software team
chooses to create data models as part of overall requirements modeling. The entity-
relationship diagram (ERD) defines all data objects that are processed within the system, the
relationships between the data objects and the information about how the data objects are
entered, stored, transformed and produced within the system.
Noun Identification
1 Android S
2 Application S
3 Authentication P
4 User P
5 System P
6 People S
56
7 Account P
8 Form S
9 First name S 4
10 Last name S 4
11 Email-id S 4
12 Address S 4
14 Message S 8,9,10,12,13,45
15 Length S 8,9,10,12,13,45
16 Database P
17 Information S
19 Location S 4,25,44
20 Interface S
21 Map P
22 GPS S 21
23 Services S
24 Detail S 25,39
25 Place P
26 Shop P
27 Area S 25,44
28 Cache S
29 Latitude S 25,44,39
30 Longitude S 25,44,39
31 Navigation P
32 Mode S 36,37
33 Marker S
57
34 Source S 36,37
35 Destination S 36,37
36 Direction P
37 Route P
38 Point S 39, 44
39 Waypoint P
40 Multimedia S 36, 39
41 Audio S 36
42 Sender S 45
43 Receiver S 45
44 Geo-fence P
45 Notification P
46 User_id S 4
47 Place_id S 25
48 Geofence_id S 44
49 Notification_id S 45
50 Route_id S 37
51 Distance S 37
52 Polygon S 36,37,44
53 Radius S 44
54 Center S 44
55 Parent S 4
56 Children S 4
Table 1: Noun Identification
58
Potential Data Objects:
● Address, polygon, multimedia are attributes of other data object. So they are not
considerable
● All other data objects can be used as data objects as they have enough importance in the
system.
1 User: U_id, first name, last name, email, address, phone number, parent, children
59
Figure 28: Entity Relationship diagram for E-Shongee
Relational Schema
60
User
Attribute Type Size
U_id NUMBER
Location VARCHAR2 80
Name VARCHAR2 50
Email VARCHAR2 50
Address VARCHAR2 80
Place
Attribute Type Size
P_id NUMBER
Location VARCHAR2 80
Detail VARCHAR2 80
Latitude NUMBER
Longitude NUMBER
Table 4: Relational Schema (Place)
61
U_id NUMBER
Location VARCHAR2 80
Name VARCHAR2 50
Email VARCHAR2 50
Address VARCHAR2 80
P_id NUMBER
Frequency NUMBER
Location VARCHAR2 80
Detail VARCHAR2 80
Latitude NUMBER
Longitude NUMBER
Table 5: Relational Schema (User Searches Place)
Sender_id NUMBER
Receiver_id
Location VARCHAR2 80
Name VARCHAR2 50
Email VARCHAR2 50
Address VARCHAR2 80
Route
Attribute Type Size
62
R_id NUMBER
Source VARCHAR2 80
Destination VARCHAR2 80
Mode VARCHAR2 80
Polygon VARCHAR2 80
Distance NUMBER
Table 7: Relational Schema (Route)
User_id NUMBER
Location VARCHAR2 80
Name VARCHAR2 50
Email VARCHAR2 50
Address VARCHAR2 80
R_id NUMBER
Source VARCHAR2 80
Destination VARCHAR2 80
Mode VARCHAR2 80
Polygon VARCHAR2 80
Distance NUMBER
Sender_id NUMBER
63
Receiver_id NUMBER
Location VARCHAR2 80
Name VARCHAR2 50
Email VARCHAR2 50
Address VARCHAR2 80
R_id NUMBER
Source VARCHAR2 80
Destination VARCHAR2 80
Mode VARCHAR2 80
Polygon VARCHAR2 80
Distance NUMBER
Table 9: Relational Schema (User Shares Route)
R_id NUMBER
W_id NUMBER
Latitude NUMBER
Longitude NUMBER
Multimedia VARCHAR2 80
Source VARCHAR2 80
Destination VARCHAR2 80
Mode VARCHAR2 80
Polygon VARCHAR2 80
Distance NUMBER
Table 10: Relational Schema (Route Contains Waypoints)
64
User creates Geo-fence
Attribute Type Size
G_id NUMBER
Area NUMBER
Polygon VARCHAR2 80
Radius NUMBER
Latitude NUMBER
Longitude NUMBER
Parent_id NUMBER
Child_id NUMBER
Location VARCHAR2 80
Name VARCHAR2 50
Email VARCHAR2 50
Address VARCHAR2 80
65
Class-based modeling represents the objects that the system will manipulate, the operations that will
applied to the objects, relationships between the objects and the collaborations that occur between
the classes that are defined.
To identify the potential classes, nouns were selected from the solution space of the story. These
were then characterized in seven general classifications. The seven general characteristics are as
follows:
1. External entities
2. Things
3. Events
4. Roles
5. Organizational units
6. Places
7. Structures
Following are the specifications of the nouns according to the general classifications.
# Noun GC
1 Android 2
2 Application 2
3 Authentication 3
4 User 1,2,4
5 System 2,4,7
6 People 1,2
7 Account 2
8 Form
66
9 First name
10 Last name
11 Email-id
12 Address
13 Phone number
14 Character
15 Length
16 Database 2,4,7
17 Information 2
18 Verification code 4
19 Location 2,6
20 Interface 2
21 Map 1,2,7
22 GPS 2
23 Services 3
24 Detail
25 Place 1,6
26 Shop 6
27 Area
28 Cache
29 Latitude 2
30 Longitude 2
31 Navigation 3
32 Position
33 Marker
34 Source 6
35 Destination 6
67
36 Direction 2,6,7
37 Route 2,4
38 Point 2
39 Waypoint 2,6
40 Multimedia 4
41 Audio
42 Sender 2,4
43 Receiver 2,4
44 Geo-fence 2,3,4
45 Notification 2,4
46 User_id
47 Place_id
48 Notification_id
49 Geofence_id
50 Route_id
51 Process 4
52 Polygon
53 Radius
54 Circle
55 Parent 4
56 Children 4
Table 12: Noun of General Classification
The potential classes were then selected as classes by six Selection Criteria. A potential class becomes
a class when it fulfills all six characteristics.
1. Retained Information
2. Needed Services
68
3. Multiple Attributes
4. Common attributes
5. Common operations
6. Essential requirements
# Noun AC
1 Authentication 1,6
2 User 1,2,3,4,5
3 System 1,2,3,5,6
4 People 3,4
5 Database 1,2,5,6
6 Location 1,3
7 Map 1,2,3,5
8 Place 1,3
9 Shop 1
10 Navigation 2,6
11 Direction 1,4
12 Route 1,2,4,5,6
13 Waypoint 1,2,3,6
14 Multimedia 1
15 Geo-fence 1,2,3,4,6
16 Notification 1,2,4,6
Table 13: Potential Classes
The nouns and the verbs associated with the potential classes are identified to find out the
attributes and methods of each class.
69
# Potential Class Noun Verb
2 System Database, users, Sign up, sign in, log out, update database, load
waypoints, map map, store waypoints, search place, generate
route, create geo-fence for users
3 Database Table name, status, key Insert, update, delete, access, store data
4 Map Api key, location, Browse map, get location information, show
marker, waypoints, user position, load place data, draw polygon,
polygon, geo-fence remove polygon, edit polygon, show restriction
2 System Database
users
70
Waypoints
map
4 Map Location
Marker
Polygon
geo-fence
5 Route Waypoints
Source
Destination
Mode
6 Waypoint Latitude
Longitude
Detail
Type
multimedia
7 Geo-fence Type
Polygon
Center
points
8 Notification Sender
receiver
Table 15: Attribute Selection
1 User ● getName()
● setName()
● getProfilePicture()
● setProfilePicture()
● getAddress()
● setAddress()
● getParent()
● setParent()
71
● getChildren()
● setChildren()
2 System ● initializeDatabase()
● initializeMap()
● validateCode()
● signUp()
● signIn()
● signOut()
● addParent()
● removeParent()
● addChild()
● removeChild()
● searchPlace()
● addRoute()
● removeRoute()
● modifyRoute()
● addGeofence()
● removeGeofence()
● modifyGeofence()
● sendNotification()
3 Database ● insert()
● delete()
● update()
● search()
4 Map ● loadMap()
● getUserPositiion()
● setUserPosition()
● getMarkers()
● setMarkers()
● drawPolygon()
● editPolygon()
● removePolygon()
● getPlaceData()
● getRoute()
● setRoute()
● getRestrictions()
● setRestrictions()
● showRestrictions()
● changeView()
5 Route ● getSource()
● setSource()
● getDestination()
● setDestination()
● getMode()
● setMode()
● getWaypoints()
72
● setWaypoints()
6 Waypoint ● getLatitude()
● setLatitude()
● getLongitude()
● setLongitude()
● getDetail()
● setDescription()
● getMultimedia()
● setMultimedia()
● modifyMultimedia()
7 Geo-fencing ● getType()
● setType()
● getPoints()
● setPoints()
● getPolygon()
● setPolygon()
● getCenter()
8 Notification ● generateMessage()
● parseMessage()
● sendNotification()
Table 16: Method Identification
To identify the final classes, it was required to check if there can be any hierarchies, merges,
additional attributes, methods or classes. These identifications are given below:
1. No separate class for parent and child is required as the functionalities are similar and
the difference can be compared using a tag. Thus separating the two as subclasses of
user class is unnecessary.
2. Since places and waypoints indicated related attributes and methods in potential
classes, they were merged as waypoints. The same is done for directions and routes
and merged as route.
3. No authentication class is required as system can monitor the functionalities with the
cooperation of the database class.
73
6.8 Class Cards
User
Attributes Methods
Responsibility Collaborator
System
Attributes Methods
● Database ● initializeDatabase()
● User ● initializeMap()
● Route ● validateCode()
● Map ● signUp()
● Polygon ● signIn()
● signOut()
● addParent()
● removeParent()
● addChild()
● removeChild()
● searchPlace()
● addRoute()
● removeRoute()
● modifyRoute()
● addGeofence()
● removeGeofence()
● modifyGeofence()
● sendNotification()
74
Responsibility Collaborator
● Sign up ● User
● Sign in ● Database
● Log out ● Map
● Update database
● Search place
● Generate route
● Create geo-fence for users
Table 18: Class Card (System)
Database
Attributes Methods
Responsibility Collaborator
Map
Attributes Methods
● Location ● loadMap()
● Markers ● getUserPositiion()
● Polygon ● setUserPosition()
● Geo-fence ● getMarkers()
● Route ● setMarkers()
● drawPolygon()
● editPolygon()
● removePolygon()
● getPlaceData()
● getRoute()
● setRoute()
● getRestrictions()
● setRestrictions()
● showRestrictions()
75
● changeView()
Responsibility Collaborator
Route
Attributes Methods
● Source ● getSource()
● Destination ● setSource()
● Waypoints ● getDestination()
● Mode ● setDestination()
● getMode()
● setMode()
● getWaypoints()
● setWaypoints()
Responsibililty Collaborator
Waypoint
Attributes Methods
● Latitude ● getLatitude()
● Longitude ● setLatitude()
● Detail ● getLongitude()
● Multimedia ● setLongitude()
● getDetail()
● setDescription()
● getMultimedia()
● setMultimedia()
● modifyMultimedia()
Responsibility Collaborator
76
● Store multimedia ● Route
● Show place detail
Table 22: Class Card (Waypoint)
Geo-fence
Attributes Methods
● Type ● getType()
● Points ● setType()
● Polygon ● getPoints()
● Center ● setPoints()
● getPolygon()
● setPolygon()
● getCenter()
Responsibility Collaborator
Notification
Attributes Methods
● Sender ● getMessage()
● Receiver ● setMessage()
● Message ● getSender()
● setSender()
● getReceiver()
● setReceiver()
● parseMessage()
● sendNotification()
Responsibility Collaborator
77
6.8 UML Diagram
78
Figure 29: UML diagram for E-Shongee
79
7.1 Introduction
The DFD takes an input-process-output view of a system. In the figures, data objects are represented
by labeled arrows and transformations are represented by circles.
80
Figure 31: Level 1 DFD diagram for E-Shongee
81
Figure 32: Level 2.1 DFD diagram for E-Shongee
82
Figure 33: Level 2.2 DFD diagram for E-Shongee
83
Figure 34: Level 2.3 DFD diagram for E-Shongee
84
Figure 35: Level 2.4 DFD diagram for E-Shongee
85
Chapter 8: Behavioral Model
The behavioral model indicates how software will respond to external events.
State diagram represents active states for each class the events (triggers).
86
Figure 37: Geofence Class State Diagram for E-Shongee
87
Figure 38: Map Class State Diagram for E-Shongee
88
Figure 39: Notification Class State Diagram for E-Shongee
89
Figure 40: Route Class State Diagram for E-Shongee
90
Figure 41: System Class State Diagram for E-Shongee
91
Figure 42: Waypoint Class State Diagram for E-Shongee
Sequence diagram indicates how events cause transitions from object to object.
92
Figure 43: Sequence diagram (Sign In)
93
Figure 44: Sequence diagram (Sign Up)
94
Figure 45: Sequence diagram (Manage Account)
95
Figure 46: Sequence diagram (Browse Map)
96
Figure 47: Sequence diagram (Search Place and Show Details)
97
Figure 48: Sequence diagram (Set Direction Aid)
98
Figure 49: Sequence diagram (Edit Direction Aid)
99
Figure 50: Sequence diagram (Send Direction Aid)
100
Figure 51: Sequence diagram (Set Parental Control)
101
Figure 52: Sequence diagram (Edit Parental Control)
102
Figure 53: Sequence diagram (Restrict Area)
103
Figure 54: Sequence diagram (Edit Restrict Area)
104