Android based crime manage system industrial project i

Android based Crime Management System Industrial project I 2016/2017
Wollega University 4th year Computer science student Page i
ANDROID BASED CRIME
MANAGEMENT SYSTEM
INDUSTRIAL PROJECT I
Wollega University, Nekemte, Ethiopia
2017 G.C or 2009 Ethiopian Calendar
Team Leader Beresa Abebe
Advisor:Mr.MulgetaBaru

Wollega University 4th year Computer science student Page ii
Table of Contents
CHAPTER ONE............................................................................................................................. 1
1. Introduction............................................................................................................................. 1
1.1. Background Information .................................................................................................. 1
1.1.1. Strength and weakness of current system ................................................................. 2
1.2. Background of the projects .............................................................................................. 2
1.3. Statement of the Problem................................................................................................. 3
1.4. Objective of Project.......................................................................................................... 3
1.4.1. General Objective ..................................................................................................... 3
1.4.2. Specific Objective..................................................................................................... 3
1.5. Scope and Limitation of the Project................................................................................. 4
1.5.1. Scope......................................................................................................................... 4
1.5.2. Limitation.................................................................................................................. 4
1.6. Feasibility Analysis.......................................................................................................... 4
1.6.1. Operational /Organizational Feasibility.................................................................... 5
1.6.2. Technical Feasibility................................................................................................. 5
1.6.3. Economic Feasibility ................................................................................................ 5
1.7. Significance of the Project ............................................................................................... 5
1.8. Beneficiaries of the System.............................................................................................. 6
1.9. Methodology of the Project.............................................................................................. 6
1.9.1. Data collection .......................................................................................................... 6
1.9.2. Data Analysis............................................................................................................ 7
1.9.3. Tools to Use.............................................................................................................. 7
1.10. Risk and Constraints..................................................................................................... 8
1.10.1. Risk........................................................................................................................ 8
1.10.2. Action Taken......................................................................................................... 8
1.10.3. Constraints............................................................Error! Bookmark not defined.
CHAPTER TWO ............................................................................................................................ 9
2. DESCRIPTION OF THE EXISTING SYSTEM ................................................................... 9
2.1. Description of the existing system ................................................................................... 9
2.1.1. Players of the existing system................................................................................... 9
2.2. Major functions of Existing System with clear Inputs, Outputs and Process ................ 10

Wollega University 4th year Computer science student Page iii
2.3. Business Rules................................................................................................................ 10
2.3.1. Categories of Business Rule ................................................................................... 10
2.3.2. Constraints (here called “action assertion”).............Error! Bookmark not defined.
2.3.3. Business Rule regarding the detectors .................................................................... 10
2.4. Report Generation in Existing System........................................................................... 10
2.5. Forms and Documents used in the Existing System ...................................................... 11
2.5.1. Form Lists............................................................................................................... 11
2.5.2. Documents list ........................................................................................................ 16
2.6. Problems of Existing System using pieces frame work................................................. 16
2.7. Practice to be preserved from Existing system .............................................................. 17
2.7.1. Strength................................................................................................................... 17
2.7.2. Weaknesses............................................................................................................. 17
2.8. Alternative Options to Address Problem of Existing System........................................ 17
2.9. System Requirement of the new System (Functional and Non-functional)................... 18
2.9.1. Functional Requirement.......................................................................................... 18
2.9.2. Non-Functional Requirements................................................................................ 18
CHAPTER THREE ...................................................................................................................... 20
3. MODELING ......................................................................................................................... 20
3.1. Use-case Diagram .......................................................................................................... 20
3.1.1. Use-case diagram of police officer ......................................................................... 21
3.1.2. Use-case diagram of administrator ......................................................................... 22
3.1.3. Use-case diagram of Member ................................................................................. 23
3.1.4. Use-case diagram of visitor .................................................................................... 24
3.2. Use-case Documentation................................................................................................ 24
3.2.1. Descriptions of Actors ............................................................................................ 24
3.2.2. Descriptions of use case.......................................................................................... 25
3.3. Sequence Diagram.......................................................................................................... 46
3.3.1. Sequence diagram of validate user ......................................................................... 47
3.3.2. Sequence diagram of add member.......................................................................... 48
3.3.3. Sequence diagram of add police ............................................................................. 49
3.3.4. Sequence diagram of add feedback......................................................................... 50
3.3.5. Sequence diagram of add criminal detail................................................................ 51

Wollega University 4th year Computer science student Page iv
3.3.6. Sequence diagram of add complaint form .............................................................. 52
3.3.7. Sequence diagram of view station .......................................................................... 53
3.3.8. Sequence diagram of view report ........................................................................... 54
3.3.9. Sequence diagram of report generating .................................................................. 55
3.4. Analysis level of Class Diagram (Conceptual Modeling).............................................. 56
3.5. Business Rule of the new System .................................................................................. 57
CHAPTER FOUR......................................................................................................................... 58
4. SYSTEM DESIGN ............................................................................................................... 58
4.1. Introduction.................................................................................................................... 58
4.2. Class Type Architecture................................................................................................. 58
4.3. Class Modeling............................................................................................................... 60
4.4. Component Modeling..................................................................................................... 61
4.5. Deployment Modeling.................................................................................................... 62
4.6. Persistence Data Management ....................................................................................... 63
4.7. Mapping (Hardware and Software Mapping) ................................................................ 64
4.8. Object Model (Revised Class Diagram and Service Specification)............................... 66
4.8.1. Revised class diagram............................................................................................. 66
4.8.2. Service specification ............................................................................................... 67

Wollega University 4th year Computer science student Page 1
CHAPTER ONE
1.Introduction
1.1. Background Information
In Ethiopia there is no any computer based method to handle day to day activities of crimes happen.
Since now we are trying to develop a system that conveys good ways to handle those things. The
Crime Management System (CrimeManSys) provides optimal as possible as plan for crime reports
and managements. So many countries are faced with these problems of crime reporting and
managements of handlings. Now days the members of peoples make crime are highly developed
and educated than police officers. To make more peoples are concerned to this and help to stop
crimes this system can improve knowledge methods of all citizen become crime fighter.
CrimeManSys is designed and implemented as an interactive program that
1. Enables entering data like:
 Data of police officer
 Data of comminuting police
 Data of suspected person
 Data of guest registrations and other constraints related to the
Crime Management System
2. Enables automatic sending of data to the server
3. Makes it possible of automatic updates of data’s
4. Automatic generating of the reports at the end of the week
Making all this possible the system make good life with of crimes and reduce the crime happening
day to days. In our country there is so many problems that the police officer may face with. Some
of them are:
 Lack of quickly reaching incident place on times
 Lack of technology to identify the crimes
 Lack of economy and others
Because of all this we come up with an idea of creating android based CrimeManSys using MySQL
for database purpose and PHP, Java, XML, other programming languages. So, this system will

provide automatic sending of crime data’s to the police officer when the server is running and the
manual labor killing will be reduced and time and lack of transportation have been conserved.
1.1.1. Strength and weakness of current system
1.1.1.1. Strength of current system
 Arranging comminuting police in society.
 Wearing police officers uniforms.
 Always arranging police officers at their local office (Zone)
 Keeping governments and non-governments organizations.
 Using walkie-talkie for quickly sending information.
 Creating connections with peoples.
The system we are developing will take these strong sides of the current system and some new
features to these functionalities.
1.1.1.2. Weakness of current system
The existing methodology of crime management is not very better ways of crime handling.
Because it has problems like:
 Lack of technology.
 Lack of transportations.
 Criminals have high knowledge of technology.
 Hard to gather information concerning crimes.
 Lack moderated materials.
 Collecting the crime effect is very hard.
 Lack of evidences to justify conviction of the perpetrator.
 Use file based system that consume time and labor.
 Unable to generated automatic crime report.
1.2. Background of the projects
The reasons that initiate us to develop this project is that we understand the importance of
technology in our day to day class learning and guessing where the world is moving now. As well
by guessing if our country police officers use technology based methods struggling with peoples
making crimes may reduce.

On other hands, as a graduated students this kind of project which requires the implications of
many course we studied which will help us to know more about the course and how they are
practiced in the real world. So we decide to develop this system which is classy one.
1.3. Statement of the Problem
Since the current system is file based and not computerized ways it faces so many problems include
technological, transport, material and lack of moderate knowledge those all problems are listed
under the following. Those are:
 Hard to gather information concerning crimes.
 Lack moderated materials.
 Collecting the crime effect is very hard.
 Police officers force and the society are not equals.
 Lack of evidences after suspected person.
 Unable to generated automatic crime report.
1.4. Objective of Project
1.4.1. General Objective
The main objectives of this projects is to improve the crime reports and management system by
using computer and android based. As well making the system more interactive and user-friendly.
1.4.2. Specific Objective
To achieve the above mentioned general objective, the project will also address the following
specific objectives.
 To store, provide information of crime managements.
 To minimize delays of information and evidence gathering.
 To reduce time consuming to complete crime investigation.
 To allow detector automatically get information.
 To make more peoples fight crimes easily and readily.
 To make crime awareness among the local community.

1.5. Scope and Limitation of the Project
1.5.1. Scope
The main scope of this project is to develop an android based crime management system which is
easily accessible to the people and the police officers using their own android based mobiles. This
system provides proper security and reduces the manual works of file based system.
As a general the scope of this software is as follows:
 Ensure data’s accuracy.
 System can report a crime to the crime authority.
 Anyone can report crime to the crime authority.
 Minimize manual data entry.
 Greater efficiency and better services.
 Reduce job of detectors.
 User friendly and interactive.
 Minimum time required.
 Generates crime reports.
 The camera and video capturing are online.
 We make all functionalities to be backed up to the servers.
 Include GPS (geographical positioning system).
 Assigning the police officer to the concerned Zones.
1.5.2. Limitation
Even though this project focuses on the crime reporting and managements systems it doesn’t
include the following
 It doesn’t bring the criminals to the court.
 It doesn’t work without connection except reading article book.
 It doesn’t upload videos or image but capture and send online.
 Not help to find perpetrators who abscond from the investigators.
1.6. Feasibility Analysis
In this phase we have seen different feasibility measures such as, operational feasibility, technical
feasibility, and economical feasibility of the new system.

1.6.1. Operational /Organizational Feasibility
It might not be possible to see fully operational system within the given limit of time for software
development. However with great cooperation of the project team the system can address over all
problems of the current system.
1.6.2. Technical Feasibility
Usually new systems established in order to overcome the technical illness of the previous system.
In the same way, this system is technically big enough to be applied easily to the problem identified
in the existing system. In addition, the both hardware’s and software’s for this system are highly
available and can be owned with small cost. Therefore, it can be concluded that the system is
technically feasible.
1.6.3. Economic Feasibility
Economically our system provide many things that can use so much money to get in the existing
system. Among many economic feasibility of our system some of them are listed below:
 Fastest getting information.
 Small response time and many services.
 Easy and fast file management.
 Reduce cost for manual data management (Reduced expenses).
 Easy update & retrieval on stored records.
 Better decision making.
 Better service for crime handling.
 Little job burden for detectors and other police offices.
1.7. Significance of the Project
The newly proposed system will have many advantages in terms of police, detectors, society and as
well for the country in the following ways:-
 None missing of criminal information.
 Non wastage of time due to crime effect finding.
 To use fast, attractive and modern service.

 Police office can access their daily working zones easily using their mobiles.
 The placement of police officer will be effective.
 Minimize wastage of resources including energy.
 It speeds up communication and cooperation between peoples and police
 Automatically send message to the suspected person.
 It will capture time, date and place where incidence (crime) happen.
 Automatically send message for calling witness “Ragaa ማስረጃ”.
 Helps the investigating police officer to get fresh information.
 The system is portable.
 Helps to initiate investigation on priority basis.
 Enhances accuracy of information to be collected for effective use.
 Helps to perform the speedy trials.
1.8. Beneficiaries of the System
The beneficiaries of our system can be the whole our country community. Those can be
 The community: - people can learn about rule and regulations from this system
and make them to respect the Law and Culture.
 Crime Authority: - Those are Police, court and etc.
1.9. Methodology of the Project
1.9.1. Data collection
Data collection is the most important part of the project to find the main requirement of the system
and to understand how the system works. We are going to use different methods to collect data.
Among the methods, we use the following:
 Observations:- to analyze the organization the previous crime management system
 Document analysis: - to get information about ways of crime managements from 2nd
district (ወረዳ) police office at Nekemte town.
 Interview:- for gathering direct information from the Commanders and other polices

1.9.2. Data Analysis
We are going to use object oriented approach and UML for the purpose of analyzing the data. The
main reason behind using OOA and UML is:
 In order to check reusability of the current crime management system in Ethiopia
 In order to define new or modify objects that can be combine with the current system
1.9.3. Tools to Use
The tools we are going to use for documents analysis in our projects are:
 Microsoft office 2007, 2013 for the purpose of writing the documentations
 Microsoft office VISIO professional 2007 for the purpose of drawing the use-
case, class, activity and other drawing.
During implementations we use:
1.9.3.1. For front end:
 Android Studio version 2.2 is best IDE tools for android development than
others like eclipse, Itellij IDEA or etc.
 JDK for java and android SDK for android developing.
 JavaScript for the purpose of client side validation.
 WAMP server is used for the purpose of writing online internet programming.
 and others
1.9.3.2. For back end:
 MYSQL is used for the purpose of data storages.
 and other

1.10. Risk and Constraints
1.10.1. Risk
While we are developing our projects we may encounter different problems among:
 The computer virus and failures are some of them.
 Power fluctuations and loss in the laboratories if computer is desktop and online laptop.
1.10.2. Action Taken
As a problems exist the solution as well be exist. Some solutions for problems are:
 Scanning the computer with antivirus and recovering the files.
 Using additional laptop and working with them.
 Always using backup after changing data of files.

CHAPTER TWO
2.DESCRIPTION OF THE EXISTING SYSTEM
2.1. Description of the existing system
The Current System of the Crime Management system is file based which is time and labor
consumer. The detector collect the data from peoples, blood strain, and hair on that place. Based
on thus data the detector and other police start the working to gain information corning the
criminals. Then they will continue till to get the exact information then present in front of the court.
Others are when compliant is want to complain someone he has to come the police officer biro and
start to fill the compliant forms manually. To call the suspected person they will print out the form
then manually fill that form after that send the form with the help of other person.
2.1.1. Players of the existing system
An actor is anyone or anything that must interact with the system, or a role that user plays with
respect to the system. Each actor has set of goals. In our case, we classified the actor that is found
in the existing system in to primary actor and secondary actor.
2.1.1.1. Primary actors
These actors are actors who directly initiate the system to run. We can classify this actor as the
main actor who plays the main role in the system. In the existing system these actors interact with
each other to fulfill the required tasks. Those actors are listed below:
 Commander (District Administrator)
 Criminal Detection Room
2.1.1.2. Secondary actors
Those actors are who works under Primary actors. They do only what main actor order them to do.
Those actors are:
 Crime detector
 Comminuting police

2.2. Major functions of Existing System with clear Inputs,
Outputs and Process
The major functions of the existing system are namely:
 Assigning community police.
 Filling new police and complaint Information.
 Filling the new data of Community police
 Enter Zone information.
 Enter suspected information.
 View community police at different zones
How the police officer get information
Input:-
 Crime happens at some place
Process:-
 After the incidence (crime) the police will reach that place and start to
investigate about the crimes by using different methods.
Output:-
 After some time the detector get the information’s
2.3. Business Rules
A business rule describes how people think and talk about things .Thus, defining a term is
establishing a category of business rule.
2.3.1. Business Rule regarding the detectors
 The detector must be not talkative.
 The detector always try to investigate the truth about incidence (crimes).
2.4. Report Generation in Existing System
The report generated in the existing Criminal Management system is somewhat in different
manner. Those concerning number of Comminuting police and society are always generated
annually once. Those corning criminal are generated weekly. That means the report in the existing
system are not computer based but they are written by using paper, pen, as well pencil and other
material used for drawing and writing.

2.5. Forms and Documents used in the Existing System
Totally the existing system is a paper based, that is time and labor consuming works. Many forms
used in this existing system are drawn by pen and ruler. After drawing they start to fill the data’s
concerning that forms what they needs. They use different forms and documents. Those forms and
documents are started from 1 to n where n is the last number. In short forms and documents are
listed below in a simple ways.
2.5.1. Form Lists
 Adding new community police: - fill all the required information of the new
community police.
 Adding annually Renter and Renting society: - fill up all required info of the
renter and renting society.
 Registering new police officer: - fill up all required info of the new police
 Adding the new complaint: - fill up all the required info of the complaint.
 View all the above filled
 Add suspected person fill

2.5.1.1. Form of calling suspected person

2.5.1.2. Form of complaint registration

2.5.1.3. Form of witness calling

2.5.1.4. Form of Compliant at court

2.5.2. Documents list
 All the day to day records of crimes happen will be documented.
 Report specific police investigation files.
 Medical/traffic evidences and other written evidences.
 Forgery- forged documents.
 Forensic (medical) evidences certificate.
2.5.3. Physical evidence
 Instruments used to commit a crime.
 Blood strain, hair, and other body fluids.
2.6. Problems of Existing System using pieces frame work.
Difficulty in reports generating, not user friendly: Manual operator control: Lot of paper work:
Inability of sharing the data.
 Difficulty in report
 The officer dealing with a particular case cannot take decision by himself even when
he is having the firsthand knowledge/information about the case and he can expect
obstructions from higher authorities/officials.
 Even an efficient officer cannot/may not be able to handle more than one case at a time.
 As we all know, a covered truth, Bribery plays an important role in the existing system.
 Many cases are piled up in the corners, which are not proved, due to lack of commitment
in the job.
 In most of the cases, the innocent are accused in the existing system.
 The existing system could provide only investigation and there is no Advocating,
Counseling facilities etc. hence no contact or control or co-ordination on these cell.
 They criticized it for being inefficient, time consuming, and poorly managed, disparate
and lacking flexibility.
 Evaluation requires monitoring crime before, during and after the initiative.
 Facts other than these initiatives may also impact on crime levels which makes
evaluation particularly difficult.

 Because of the amount of serious crime, lesser crime goes unchecked. Many crimes
become regarded as antisocial activities.
2.7. Practice to be preserved from Existing system
This project will come up with a solution that can minimize the above listed problems of the system
in the organization and enable the police officer to be effective and efficient by considering the
limited resources they have. By considering those strengths of the existing system. We conserved
all the strength of the existing system already mentioned in the chapter 1 under 1.1.1.1 heads.
2.7.1. Strength
 The whole community and police officers are very cooperative or eager for their
duties performed even if it is a tiresome duty.
2.7.2. Weaknesses
 Lack of data integrity.
 High exposure to record error.
 Difficulty in managing information, poor or corrupted filing system and
difficulty to get the required information easily as possible.
2.8. Alternative Options to Address Problem of Existing
System
We have an alternative option in order to solve problems that exist in the functioning of the existing
system of crime management.
 To have a way that allow customers use different facilities provided by the
system being online.
 Developing system that assign police officer to different zone.
 Storing updated information on the system.
 Better communication, better leadership, better training, and more defined roles
in terms of contribution to the society.
 Working with partners.
 Develop system that send message to suspected and witness.

 Develop system that store data of complaint.
 Develop system that register new Police.
 Reducing crime and disorder.
 Confidently and anonymity issues.
2.9. System Requirement of the new System (Functional and
Non-functional)
2.9.1. Functional Requirement
The functional requirements are functions or features that the system must include to satisfy the
system need and to be acceptable by the user. The functional requirements for the new system that
will replace the existing system include:
 The system will allow insert police officer information.
 The system should provide password changing facility.
 The system should provide user authentication mechanism.
 The system should be able to generate report.
 Storing, updating and deleting records.
 Validate data and store it without error.
 Assign police officers for each zones.
2.9.2. Non-Functional Requirements
2.9.2.1. User interface and human requirements
The system provides web based and mobile based application user interfaces that are compatible
with any platforms.
2.9.2.2. Hardware Requirements
The departments should have desktop computers having typical storage capacity and processing
speed.

2.9.2.3. Software requirements
The department should have MySQL server on the computer having typical storage capacity and
processing speed. In addition, the department should have internet explorer or any other browsers
and some anti-spy wares in order to protect the database from spy.
2.9.2.4. Security issue
This system provides an access to privilege to an authorized user by giving account for each and
every special function. In addition, the system is with session controlled way to permit URL based
system access.
2.9.2.5. Performance characteristics
The system is accessible by specified actors in the police assign. It should be given more
emphasis for the speed to access it.
2.9.2.6. Error handling
This system handles error done by the user giving error message when the user enters wrong inputs.
In addition, the system provides error handling mechanism on the ways system interacts with data
base and on input accepter fields.
2.9.2.7. Quality issue
Information in database should be accurate and updated.
2.9.2.8. The system modifications
The system should be easily modifiable.

CHAPTER THREE
3.MODELING
3.1. Use-case Diagram
A use case is an interaction between users and a system. It captures the goal of the users and
the responsibility the system to its users. It is the functionality of the system or the service
provided by the system.

3.1.1. Use-case diagram of police officer

3.1.2. Use-case diagram of administrator

3.1.3. Use-case diagram of Member

3.1.4. Use-case diagram of visitor
3.2. Use-case Documentation
3.2.1. Descriptions of Actors
In this system we have four actors. Namely:
1. Name: Administrator
Description: An Administrator is a person who
 Manage account,
 Manage own account
 View station,
 View feedback
 Give feedback,
 View crime detail,
 View article book,
 Give report
2. Name: Member
Description: A members those who are voluntary engaged to protect the
crimes and send different information concerning the crimes to the police officer.
They have right to:
 Manage their own
account,
 View crime detail,
 Give report,
 View station,
 Give feedback,
 View article book
and other
responsibility in the
system.

3. Name: Police Officer
Description: A police officer is a police who administrators other police and
who:
 manages members,
 manage article book,
 manage report,
 manage complaint
 manage feedback,
 manage crime detail,
 manage suspected,
 manage police,
 manage station,
 manage witness
account
 view station,
 give feedback,
 view feedback
 view crime detail,
 View article book.
The police officers have full responsibility on each and every thing that
concern polices.
4. Name: Visitor
Description: A visitor is a people who is guest for the system but he/she want
to view the system. So, they have some right to see what the system do and works.
Those are:
 View article book
 Report crime
3.2.2. Descriptions of use case
A use case is an interaction between users and a system. It captures the goal of the users and
the responsibility the system to its users. It is the functionality of the system or the service
provided by the system.
Use case lists
1. Manage member
2. Manage account
3. Manage article book
4. Mange feedback
5. Manage report
6. Manage police
7. Manage suspected
8. Manage crime detail

9. Manage witness
10. Manage station
11. Manage own account
12. Manage complaint
13. View station
14. Give feedback
15. View article
16. Send criminal report
17. View crime detail
18. View feedback
19. Login
20. Validate user
3.2.2.1. Use case name: Manage member
Actor: Police Officer
Description: Add, delete, and modify member’s activity
Precondition: Member is identified and then authenticated
Include: login
Extends: validate user
3.2.2.1.1. Flow of Event
3.2.2.1.1.1. For Add Member
1. The authenticated actor wants to add member
2. The user wants to register to be a member
3. The user wants to fill all information need to be a member
4. The user registered
5. The use case end
Post Condition: New member added to database
3.2.2.1.1.2. For Delete Member
1. The authenticated actor wants to remove member.
2. The authenticated actor logs in to the system.
3. The authenticated actor searches the member to be removed.
4. The authenticated actor click remove button
5. The system removes the member from the database
6. Use case ends
Post Condition: Member is deleted from database
3.2.2.1.1.3. For Modify Member
1. The actor wants to modify an existing room.
2. Authenticated actor logs in.

3. The actor search the room to be changed [Alternative]
4. The actor click edit button.
5. The system edits the member.
6. Use case ends.
 Alternative flow:- [if not found]
 The system displays ‘information not found ‘message
 Exit
Post Condition: Member in database modified
3.2.2.2. Use case name: Manage article Book
Description: Add, delete, and modify article’s activity
Precondition: Article is identified
Include: login
3.2.2.2.1.1. For Add book
1. The authenticated actor wants to add article book
2. The user wants to add article to database
3. The user wants to fill all information need to add article
4. The article added
5. The use case end
Post condition: New article added to database
3.2.2.2.1.2. For Delete Article book
1. The authenticated actor wants to remove article
3. The authenticated actor looks article to be removed.
5. The system removes that article from the database
6. Use case ends
Post condition: Member is removed from database

3.2.2.2.1.3. For Modify Article book
1. The actor wants to modify an existing article
3. The actor search the room to be changed [Alternative]
5. The system edits the article book.
6. Use case ends.
 Alternative flow:- [if not found]
 The system displays ‘information not found ‘message
 Exit
Post Condition: The article is modified in the database
3.2.2.3. Use case name: Manage Report
Description: add, delete, modify and generate report activity
Precondition: report is identified
Include: login
3.2.2.3.1.1. For adding report
1. The authenticated user wants to add report
2. The actor login to the system
3. The actor fill the information needed to add report
4. The actor click on add report button
5. The report is added to the system
6. The use case end.
Post condition: You successfully added new report to the system
3.2.2.3.1.2. For delete report
1. The authenticated actor wants to delete report
3. The actor search report he/she want to delete ]Alternative]
4. The actor found report
5. The actor click on delete button

6. The system ask certain to delete this report
7. If yes the report is successfully deleted
8. The use case end
Post condition: You successfully deleted the report
[Alternative]:
 If the report not found
 The system display message “The report you searched was not
found. Try again.”
 The use case end
3.2.2.3.1.3. For modifying report
1. The authenticated actor wants to update the report
3. The actor search for report he/she wants to change [Alternative]
4. The actor changes what he/she wants
5. The actor click on save change button
6. The report is successfully updated message will be displayed.
7. The use case end
Post condition: The report successfully updated
 If not found in the system
 The system display message “The report you want is not found.”
 The use case end
3.2.2.3.1.4. For generating report
1. The authenticated actor activates the report generate function.
2. At this point the system responds with a general report form
and ask whether user wants to print or save
3. The authenticated actor selects the report type as required.
4. The system generates the report.
5. The use case ends.
Post condition: - Report is submitted.

3.2.2.4. Use case Name: Manage Feedback
Actor: Police officer
Description: delete the feedback if it exceeds more than given amount.
Precondition: feedback should be identified and exist in database
Include: login
3.2.2.4.1. Flow of event
3.2.2.4.1.1.For Delete feedback
1. The authenticated actor wants to remove feedback
3. The actor go to deleting feedback pages
4. The authenticated actor looks feedback to be removed.
5. The authenticated actor click delete button
6. The system removes that feedback from the system
7. Use case ends
Post Condition: The feedback deleted from database
3.2.2.5. Use case name: Manage Criminal Detail
Description: Add, delete and modify the crime detail
Precondition: crime detail should be identified and exist in database
Include: login
3.2.2.5.1.1. For Add crime detail
1. The authenticated actor wants to add crime detail
2. The user wants to add new crime detail
3. The user wants to fill all information need to add crime detail
4. The crime detail added
5. The use case end
Post condition: New crime detail added to database
3.2.2.5.1.2. For Delete crime detail
1. The authenticated actor wants to remove crime detail

3. The authenticated actor looks crime detail to be removed.
5. The system removes that crime detail from the database
6. Use case ends
Post Condition: The crime detail deleted from database
3.2.2.5.2. For Modify crime detail
1. The actor wants to modify crime detail
3. The actor looks the crime detail to be changed
5. The system edits the crime detail.
6. Use case ends.
Post Condition: The crime detail is modified in the database
3.2.2.6. Use case Name: Manage account
Actor: Administrator, Member
Description: Create new, deleting existing, modify account for user
Precondition: The is not created before and the account should exist in
the system
Include: login
3.2.2.6.1. Flow of Events
3.2.2.6.1.1. For creating new account
7. The authenticated user wants to create new account
8. The authenticated user load account page
9. The authenticated user click on option create new account
10. The form will be displayed
11. The user will fill all the form clearly
12. The user click on create account
13. Ask user for verification of email or phone

14. The user receive verification number on his/her email or
phone
15. The user add that number to space provided
16. The user confirm
17. Then, new account will be created
18. The end of use case
Post condition: successfully new account created
3.2.2.6.1.2. For deleting account
1. The authenticated actor wants to delete account
2. The authenticated actor login to the system
3. He/she search accounts to delete [Alternative]
4. The authenticate actor click on delete button
5. The account is delete
6. The use case end
Post condition: The account is deleted from the system
[Alternative]
1. If the account not exist
2. The account you searched is no exist will be displayed
3. Then ask actor to go back to main
3.2.2.6.1.3. For modifying account
1. The authenticated actor wants to modify account
3. The authenticated actor search account to be modified
[Alternative]
4. The authenticated modify account he/she wants
5. The account is modified
Post condition: The account is successfully modified

[Alternative]
1. If the account no present
2. The account you want is not existed message will be
displayed
3. Then system ask him/her to go back to searching page
4. The use case end
3.2.2.7. Use case Name: Manage police
Actor: police officer
Description: add, delete, modify and assign police
Precondition: Police not registered before, not assigned to ay zone before,
the should be registered police
Include: login
3.2.2.7.1.1. For police registration
1. The authenticated actor wants to add new police
3. The authenticated actor fill all data needed to register
new police
4. The verification message will be send to the police to be
registered
5. The phone number is verified
6. The new police is registered
Post condition: New police registered
3.2.2.7.1.2. For deleting police
1. The authenticated actor wants to delete police officer file
3. Search the police file he/she wants to delete
[Alternative]

4. The system ask the actor whether he/she delete or not
5. The actor click on the delete option button
6. The police officer file deleted
Post condition: The police file is deleted
[Alternative]
1. If the police file not exist
2. The system display message “The police you want to
delete is not exist!”
3. The system ask actor whether he wants to search again
or not.
4. The use case end
3.2.2.7.1.3. For modifying police files
1. The authenticated actor wants to modify data of police
3. Then search police he/she wants to modify [Alternative]
4. The police data modified
Post condition: The police data is modified successfully
[Alternative]
1. If the police not exist
2. The system will display message “The police you want
is not present!”
3. The system ask actor whether he/she want to search
again or not
4. The use case end
3.2.2.7.1.4. For assign police to station
1. The authenticated actor wants to assign police

3. The actor assign each police to each station
4. The police assigned will receive message
5. The use case end
Post condition: All police are assigned to the station
3.2.2.8. Use case Name: Manage complaint
Actor: police officer
Description: Add, delete and modify complaint files
Precondition: Complaint must be present to the station. This is because
the Ethiopian Criminal Procedure Code requires a complaint should be
appear personally and start his/her complain.
Include: login
3.2.2.8.1.1. For adding complaint
1. The authenticated actor wants to add new complaint
3. The actor goes to complaint pages
4. The actor click on Add new complaint button
5. The actor fill all information
6. The system send verification message to complaint
7. The actor enter verification message
8. The system verifies the code
9. New complaint record is added
10. The use case end
Post condition: New complaint record is added!
3.2.2.8.1.2. For deleting complaint
1. The authenticated actor wants to delete complaint files
3. The actor goes to complaint page
4. The actor click on the button delete complaint
5. The system ask actor to search complaint to be deleted
6. The actor enter complaint to be deleted [Alternative]
7. The actor verifies deleting
8. The use case end
Post condition: The complaint exactly deleted.

[Alternative]
1. If the complaint not found
2. The system display message “The complaint you
searched is not found. Please try again!”
3. The system ask actor whether he/she search again
4. The use case end
3.2.2.8.1.3. For updating complaint files
1. The authenticated actor wants to modify complaint files
3. The actor goes to complaint page
4. The actor click on modify complaint
5. The system ask actor to search complaint he/she wants
to modify
6. The actor enter complaint to be updated [Alternative]
7. The actor changes what he/she wants to change
8. The actor click on apply change button
9. The use case end
Post condition: The complaint data is successfully changes.
[Alternative]
1. If complaint searched is not found
2. The system display message “The complaint you
searched is not found. Try again!”
3. The system ask whether he/she wants to search again
or not
4. The use case end
3.2.2.9. Use case Name: Manage suspected
Description: Add, Delete and modify suspected files
Precondition: The actor should know the phone number of suspected
Include: login
3.2.2.9.1. Flow of events
3.2.2.9.1.1. For adding suspected
1. The authenticated actor wants to add new suspected

3. The actor fill all the information needed to call
suspected
4. The actor send message to the suspected
5. The suspected receive message
6. The use case end
Post condition: The new suspected record is added.
3.2.2.9.1.2. For deleting suspected record
1. The authenticated actor wants to delete suspected
records
2. The authenticated login to the system
3. The actor search suspected record he/she wants to
delete [Alternative]
4. The system ask actor whether he/she wants to delete or
not
5. The suspected record deleted
6. The use case end
Post condition: The suspected record is deleted.
[Alternative]
1. If the record not found
2. The system display message “The suspected you want
is not exists!”
3. The system ask whether he/she search again or not
3.2.2.9.1.3. For modifying the suspected record
1. The authenticated actor wants to update suspected
records.
3. The actor search suspected he/she wants to modify
[Alternative]

4. The suspected record is modified.
5. The use case end
Post condition: The suspected record is update successfully.
[Alternative]:
1. If the suspected record not found
2. The system display message “The suspected record you
want is not exist!”
3. The system ask whether actor want to search again or
not
3.2.2.10. Use case Name: Manage Station
Description: add, delete and modify the station at different zones
Include: login
3.2.2.10.1.1. For adding station
1. The authenticated actor wants to add new station at different zone
3. The actor load station page
4. The actor click on add new station
5. The actor fill all necessary information
6. The actor click on the button add station
7. The station is added
8. The use case end
Post condition: The new station is correctly added

3.2.2.10.1.2. For deleting the station
1. The authenticated actor wants to delete the station
3. The actor load station page
4. The actor click on delete station button
5. The searching area will come
6. The actor enter station number he/she wants to remove
[Alternative]
7. The actor click on delete the station button
8. The station is removed
9. The system display message “You successfully deleted the station”
10. The system ask actor to go back to the main menu
Post condition: The station is successfully deleted.
[Alternative]
1. If the station not found
2. The system display message “The station you searched was not
found.”
3. The system ask whether he/she wants to search again or not
4. The use case end
3.2.2.10.1.3. For modifying station
1. The authenticated actor wants to update station
3. The load station page
4. The load update station page
5. The actor search station he/she wants to update [Alternative]
6. The actor fill attributes he/she wants to update
7. The actor click on button modify station
8. The station is updated
9. The use case end

Post condition: The station is successfully updated
[Alternative]
1. If the station not found
2. The system display message “The station you searched is not
found. Please, try again!”
3. The system will ask whether he/she wants to search again or not
4. The use case end
3.2.2.11. Use case Name: Manage witness account
Description: Allows police to send message to witness
Precondition: The witness device should have connection.
3.2.2.11.1.1. For the Witness calling letter
1. The police wants to call witted man
2. The police fill information needed to call witted man
3. The police send that letter information to witted man
4. The witted man receive letter through his phone
5. The use case end
Post Condition: The witted man received letter
3.2.2.12. Use case Name: Manage own account
Actor: Member
Description: Member can create, delete and modify their own account
Pre-condition: There should be allowance of creating, updating and
deleting activities in the system
Include: login

3.2.2.12.1. Flow of events
3.2.2.12.1.1. For creating account
1. The user wants to create account or wants to be a member
2. The user load login page
3. The user click on create your own account
4. The user fill all information correctly
5. The system check enter number or email if they are registered before
6. The user click on create account
7. The system send verification message to his/her email or phone
8. The user receive message
9. The system will ask verification number
10. The user enter number he/she received
11. Now the user is member of that system
Post condition: The user is successfully created new account
3.2.2.12.1.2. For updating account
1. The authenticated actor login to his/her account
2. The actor go to setting page
3. The actor click on update account page
4. The actor change attributes he/she wants to update
5. The on the last the actor click on the button update my account
6. The account is updated
7. The use case end
Post condition: The account is updated
3.2.2.12.1.3. For deleting account
1. The authenticated actor login to his/her account
2. The actor go to setting page
3. The actor load delete my account
4. The system send verification message for deleting his/her account

5. The actor receive message verification
6. The system ask to input that number
7. The actor fill the number [Alternative]
8. The actor click on delete my account button
9. The use case end
Post condition: The account is deleted from the system
[Alternative]
1. If verification number is wrong
2. The system display message “The verification number you entered is
wrong. Please, try again”
3. The system will ask whether he/she wants to receive message again
or not
4. The use case end
3.2.2.13. Use case Name: View Station
Actor: Administrator, Police officer, member
Description: view the stations
Precondition: the stations should be identified and exist in database
Include: login
For viewing station
1. The authenticated actor wants to view the zone station
2. Authenticated actor login if he/she has privilege to login.
3. The authenticated actor selects his/her need.
4. The authenticated actor click view button.
5. The station is display.
6. End the use case.
 Post condition:- The station is displayed

3.2.2.14. Use case Name: Give feedback
Actor: Administrator, Police officer, Member
Description: Add the feedback
Precondition: user should be identified and authenticated
Include: login
Extends: validate users
3.2.2.14.1.1. For give feedback
1. The authenticated actor wants to add feedback
2. The user wants to add new feedback
3. The user wants to fill all information need to add feedback
4. The feedback added
5. The use case end
Post condition: New feedback added to database
3.2.2.15. Use case Name: View feedback
Actor: - Police officer, Administrator
Description: - Allow the actor to view feedback
Precondition: There should be one feedback in the system
Flow of event
1. The authenticated actor wants to view feedback
3. The actor goes to feedback page
4. The actor click on view feedback
5. Different feedback displayed
6. The actor select feedback he/she wants to view
7. The feedback detail displayed
8. The use case end
3.2.2.16. Use case Name: View Crime detail
Actor: - Administrator, Police Officer, Member, Visitor
Description: - Allows the user to view crime detail information
Pre-condition: - The information should be exist in the database
Flow of Event

1. The authenticated actor wants to view the crime information
2. Authenticated actor login if he/she has privilege to login.
3. The authenticated actor selects his/her need.
4. The authenticated actor click view button.
5. The information is display.
6. End the use case.
Post condition: - The crime information is displayed
3.2.2.17. Use case Name: - View article
Actor: Administrator, Police officer, Member, Visitor
Description: Allow the user to view the book of article
Per-condition: The information should exist in the database
Flow of Event
1. The user want to view articles
2. The user click on the button view article
3. The system display article book
4. The user select article to view
5. The use case end
Post-Condition: The crime article book will be displayed
3.2.2.18. Use case Name: report crime
Actor: Administrators, Police officer, Member, visitor
Description: Allow the user to send crime happening at that moment
Pre-condition: The system should be running at server side
Flow of Event:
1. The user want to report crime happening
2. The user may or may not fill all information
3. The user must use of camera or videos including other
information
4. The user report crime and send data to server if sever is running
[Alternative]
5. The use case end

[Alternative]
1. If the server is not running the system display “The server
is not running please! Save to your SD card and try again
later.”
2. The system exit
3.2.2.19. Use case Name: Login
Actor: Administrator, Police officer, Member
Description: Login for the purpose of managements.
Precondition: The actors are registered before
Flow of event:
1. The authenticated actor wants to login the system
2. The actor load the login page
3. The system ask for username and password
4. The actor enter username and password
5. The actor click on login button
6. The system verify the username and password [Alternative]
7. The actor logged in to the system
Post condition: The page actor wants to be displayed.
[Alternative]:
1. If password and username is wrong
2. The system display message “Your username or
password is invalid, please! Try again. Or did you
forget your password?”
3.2.2.20. Use case name: validate user
 Actor :-Administrator, police officer, member, visitor
 Description: -Validates the user to enter to the system.

 Pre-condition: - The home page currently displayed on the screen and
the actor is ready to log in.
 Flow of events:-
1. The actor click on login button.
2. The system displays the form login.
3. The actor fills required information in displayed log in form.
4. The system verifies the data filled is correct or not.
5. The system verifies actor credentials and validates.
6. The use case ends
Alternatively:
The entered username and/or password are not correct.
1. The system determines the invalidity of username
and/or password
2. The system doesn’t grant permission to access.
3. The system informs the user to reenter username
and/or password
4. The use case resumes at step 3 of flow of events.
5. Use case ends.
 Post condition: - The person logged before.
3.3. Sequence Diagram
Sequence diagrams are used to model the logic of usage scenarios or the description of the
potential way the system used. Sequence diagrams are a great way to validate and flesh out the
logic of use case scenarios and to document the design of the system.

3.3.1. Sequence diagram of validate user

3.3.2. Sequence diagram of add member

3.3.3. Sequence diagram of add police

3.3.4. Sequence diagram of add feedback

3.3.5. Sequence diagram of add criminal detail

3.3.6. Sequence diagram of add complaint form

3.3.7. Sequence diagram of view station

3.3.8. Sequence diagram of view report

3.3.9. Sequence diagram of report generating

3.4. Analysis level of Class Diagram (Conceptual
Modeling)
Class diagrams show the model dependency between user interface classes and associations
between business classes. The following figure shows class diagram of Crime Management
system.

3.5. Business Rule of the new System
Business rule comes to identify the rule while using the system, in our system the following rules
are helps to work effectively for the system.
 The system works if and only if the required data are inserted.
 The member can’t create the double account using the same username and phone number
 The system work connection based.
 It may increase false accusation unless the awareness creation is made.
 Physical presence of the person reporting a crime or the victim is required to complete the
investigation and frame a charge against the suspect. This is because the Ethiopian
Criminal Procedure Code requires a witness to give his/her testimony in person; the
testimony should be read to the witness and finally signed by the witness.

CHAPTER FOUR
4.SYSTEM DESIGN
4.1. Introduction
Project design is the general approach given to develop the software to solve the problem of
a particular organization. Project design is the stage at which description of project
development is given and how the project is designed. The purpose of design is to determine
how to build the system and to obtain information needed to drive the actual implementation
of the system. The focus is particularly on the solution domain rather than on the problem
domain. Object oriented design consists of transforming the analysis model into the design
model. It describes the system in terms of its architecture.
4.2. Class Type Architecture
Since our system modeling approach is object oriented, we have to describe the system in terms
of its architecture, such as its hardware /software mapping, global control flow and persistency
management. Therefore, this session mainly concerned with the design part of CrimeManSys
system. In this section we will see the different types of class type architectures, such as sub
system decomposition, user interface layer, process control layer, business /domain layer,
persistent layer, system layer and also different types of system modeling techniques that are
used for the implementation types of the system such as class modeling .In addition, some
system design techniques such as user interface designing are also to be covered in this design
part. The following figure presents a high level layering strategy for software application. The
various layers are represented by the rectangles and collaboration between layers indicated by
the arrows. The primary name of the layer is indicated first, and other common names indicated
in parenthesis.

Fig.4.2.1 Layered class type architecture
2. Control/process layer
(Application, controller)
-Validate System User
3.Domain (Business)
-Feedback screen ()
-Crime reporting screen ()
-View Article screen ()
-Crime Info screen ()
4.Persistent classes (Data)
Store update Delete
Data Sources
5. System
(infrastructur
e plat form)
Classes
1. User Interface (system interface)
-Log in Form Screen ()
-Member Form Screen ()
-Article Book Form Screen ()
-Report Form Screen ()
-Police Form Screen ()
-Complaint Form Screen ()
-Station Form Screen ()
-Feedback form Screen ()

1. Interface: This layer wraps access to the system and system interface. There are two
categories of interface classes: user interface (UI) classes that provide people access to the
system and system interface (SI) classes that provide access to external systems to the
system. However, the above-mentioned classes are among user interface (UI) elements of
the system. E.g. Log in Form Screen ().
2. Control/process layer: This layer represents controller/process class that implements
business logic that involves collaborating with several business or domain classes or even
other process classes.
3. Domain: This layer implements the concepts pertinent to your business domain such as
customer focusing on the data aspects of the business objects, plus behaviors specific to
individual objects.
4. Persistence layer: This layer is used to encapsulate the capacity to store, retrieve and delete
objects permanently without revealing details of the under laying storage technology.
5. System layer: This layer is used to represents system class that provides operating system
specific functionality for the applications, isolating the software from the operating system
(OS) by wrapping OS specific feature.
4.3. Class Modeling
In class modeling the static structure of the scheduling will be built. In particular, it shows the
things such as classes and types, their internal structure and relationships, to other things.
Fig 4.3. Class Modeling

4.4. Component Modeling
The goal of component modeling is to distribute the classes of the system into the larger scale,
cohesive components. A component diagram shows dependencies among components. In our
projects we do have to component modeling. Those are: Administrator and the Police officers

4.5. Deployment Modeling
A UML deployment diagram depicts a static view of run time configuration of processing
nodes and the components that run on those nodes. In other words deployment diagrams showFig 4.4.1. Component modeling of CrimeManSys project

the hardware for the system, the software that is installed on that hardware, and the middleware
used to connect separate machines on one another.
Fig 4.5. Component Modeling of CrimeManSys Project
4.6. Persistence Data Management
Persistence data model or Entity relationship (ER) models are used to communicate the design of
a database, usually a relational database, to both users and other developers.
Persistence are used the schema of database. The strength of persistence data models is that data
entities are conceptually the same as the table of relation data base and that attributes are the same
as table columns.
Client: Browser
Webserver (Apache)
Mobile
<<App>>
Manage Member
Manage Report
Manage Police
Manage Feedback
Manage Complaint
View Article Book
Manage Station
User Account
DB Server MYSQL
Persistence
CrimeManSys<<AppLication>>
Database
Deployment Modeling of Crime Management System Project

Persistence layer encapsulate the capability to store, retrieve, and delete objects/data permanently
without revealing details of the underlying storage technology. In the current database system we
have used different tables as object and each object is related to each other and enforced by
referential integrity by the use of foreign key and primary key. This schema enables as data
manipulation activity such as select, search, delete, update on the database.
Fig 4.6. Data Persistence Modeling
4.7. Mapping (Hardware and Software Mapping)
 Hardware Mapping
The hardware used for registration system and other service of the crime management system is
an android based mobile or personal computer.

 Physical and logical connectivity
Our Proposed system has no physical connectivity, because, our proposed System is to manage a
file into database system. In addition; there are many types of constraints that we tried to inform
in this research limitation part that has limited from physical connectivity.
 Software Mapping
The system uses Microsoft Windows 8.1 Operating System. That we are working with. The
proposed system uses sublime or android studio as a text editor, PHP, JavaScript, android parts as
well we use android studio rather than using another IDE to develop the system. The system uses
MySQL server to store data.

4.8. Object Model (Revised Class Diagram and Service
Specification)
4.8.1. Revised class diagram

4.8.2. Service specification
1. Member
Attribute description for Member
 Username:- This attribute is a unique identifier for the member
 Full name:-This attribute is the first and last name of member
 Phone: - an attribute the member receive verification codes. It is unique for all
member.
 Nationality:- This attribute is used to identify the country of member or its nation
 State:- used to input the region of member
 Zone:- for zone member is involved
 Kebele:- this attribute is for Kebele member is living in
Method description of Member
 Register():- This method is used to register unregistered member
 Login():- This method is used allow members to login to his/her account
2. Suspected
Attribute description of Suspected
 Number:-This attribute is a unique identifier of suspected from one to an other
 Date:- This is the date on which message is going to send
 Mr./Mrs:- This attribute is the name of suspected person

 About:- The reason the suspected is called
 DateofCalled:- The date on which suspected called
 TimeofCalled:- The time on which suspected called
3. Witness
Attribute descriptions of Witness
 WitnessNumber:- Unique identity number assigned to the witness
 Date:- The date on which the message is send to witness phone
 To: Full name of witness persons
 About:- The reason witness person is called
 officeNumber:- The room witness person ask when come to the office
 onDate:- The date on which witness person come to the station
 onTime:- Time on which witness person contact the station

Android based crime manage system industrial project i

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Android based crime manage system industrial project i

Similar to Android based crime manage system industrial project i (20)

Recently uploaded

Recently uploaded (20)

Android based crime manage system industrial project i