Digital Broker Mobile Application

JIMMA UNIVERSITY INSTITUTE OF TECHNOLOGY SCHOOL OF COMPUTING PROGRAM: COMPUTER SCIENCE

REQUIRMENT SPECIFICATION, ANALYSIS, SYSTEM DESIGN, IMPLEMENTATION AND TESTING OF DIGITAL BROKER MOBILE APPLICATION FOR ADDIS ABABA CITY.

By Student Name

ID

Signature

1. Bekan kitaw……….………...01211/06…………………….. 2. Fekadu Abdisa…..…………..01094/06…………………….. 3. Betelhem Amdie………….....01051/06…………………….. 4. Gamada Abdisa…………….01111/06……………………..

Advisors Name

Signature

1. Ins. Behailu Shewandagn ……………………………………………… 2. Ins.Meron Gashaw………………………………………………………

Submitted to: School of Computing Submission Date: 15/10/2009

JIMMA UNIVERSITY JIMMA INSTITUTE OF TECHNOLOGY SCHOOL OF COMPUTING DEPARTMENT OF COMPUTER SCIENCE REQUIRMENT SPECIFICATION, ANALYSIS ,SYSTEM DESIGN,IMPLEMENTATION AND TESTING OF DIGITAL BROKER MOBILE APPLICATION FOR ADDIS ABABA CITY.

By Student Name

ID

Signature


NAME AND SIGNATURE OF THE EXAMINING BOARD Name

Signature

1. -----------------------------

---------------------------

2. -----------------------------

---------------------------

3. -----------------------------

---------------------------

Project Viva – Voce held on _______________________

I

Digital Broker Mobile Application 2017 GC.

Contact Information This project is submitted to the School of Computing at Jimma University in the partial fulfillment of the requirements for the degree of Bachelor of Science in Computer Science. Authors:

Student Name

ID

Email

1. Bekan kitaw……….………...01211/06

[email protected]

2. Fekadu Abdisa…..…………..01094/06

[email protected]

3. Betelhem Amdie………….....01051/06

[email protected]

4. Gamada Abdisa…………….01111/06

[email protected]

University Advisor / supervisor (s): Ins. Behailu Shewandagn Email: [email protected] School name: Computing Co-supervisor: Ins.Meron Gashaw Email: [email protected] School: Computing

II


Intellectual Property Declaration This is to declare that the work under the supervision of Ins. Behailu Shewandagn and Ins.Meron Gashaw having title “ Digital Broker Mobile Application For Addis Ababa City ” carried out in

partial fulfillment of the requirement of Bachelor of Science in 2017 is the sole property of Jimma University and respective supervisor and is protected under the intellectual property right laws and convention. It can only be considered/ used for purposes like extension for further enhancement, product development, adoption for commercial/ organizational usage, etc., with the permission of the university and respective supervisor. This above statement applies to all students and faculty members. Date:____________________ Authors:

Student Name

ID

Signature


III


Anti-Plagiarism Declaration This is to declare that the above industrial project under the supervisor of Ins. Behailu Shewandagn and Ins.Meron Gashaw

having title “ Digital Broker Mobile Application For

Addis Ababa City ” is the sole contribution of the authors and no part hereof has been reproduce illegally (cut and paste) which can be considered as plagiarism . All referenced parts have been used to argue the idea and have been cited properly. We will be responsible and liable for any consequence if violation of this declaration is proven. Date:____________________ Authors:

Student Name

ID

Signature


IV


Acknowledgment First of all our biggest thanks would be to Almighty God because nothing could be possible without his free will and the completion of this project is supported by him. Secondly, we would like to thank our honorable advisors Instructor Bahilu Shewandagn & Co-Advisor Meron Gashaw who contributed in giving us their continuous advice and comments.

V

Abstract With rapid increase in the use of mobile phones, the desire for people to access mobile internet to get information and services from anywhere and everywhere has increased. There is an increase in number of customers that need house, car, and vehicle....either for renting, selling and buying. There are also customers that need for house servants and guards through their daily lives. This proposal work aims to design and implement a remote brokering system, through which one can search for his wish, view, and make either a phone call or usual SMS with owner to negotiate and also make a payment. This application consists of three applications within itself. First is for the Admin who can register the brokers and perform any transaction on them. The second is the customer/user who can search for need and make a contact with owner. Third is for the brokers who records the item (house, car, vehicle, servant, guards) information and made all the transaction on them. We made the use of many algorithms that calculates the amount/percent paid for the broker due process. This system increases quality and speed of service. It also increases the popularity of brokers among potential customers. Implementing this system gives a cost-efficient opportunity to give customers a personalized service experience where they are in control of choosing what they want, when they want it – from searching to viewing to payment. We have chosen Android platform because it is most widely used today and is very economical.

VI


List of figures Figure 2.1 actor notation ............................................................................................................................. 19 Figure 2.2 use case notation ........................................................................................................................19 Figure 2.3 Notation for system boundary ................................................................................................... 19 Figure 2.4 Notation of include relations ..................................................................................................... 20 Figure 2.5 Notation of extend relation ........................................................................................................20 Figure 2.6 Use case diagram of the system .................................................................................................21 Fig.2.7 Sequence diagram for Broker login ................................................................................................35 Figure 2.8 Sequence diagram for view service ...........................................................................................36 Figure 2.9 Sequence diagram for post service ............................................................................................ 37 Figure 2.10 State chart diagram for Registration ........................................................................................38 Figure 2.11 State chart diagram for Login ..................................................................................................39 Figure 2.12 State chart diagram for Post service ........................................................................................ 40 Figure 2.13 State chart diagram for View service ...................................................................................... 41 Figure 2.15 State chart diagram for Make payement...................................................................................42 Figure 2.16 Activity diagram for Customer registration............................................................................. 43 Figure 2.17 Activity diagram for Login ......................................................................................................44 Figure 2.18 Activity diagram for post service ............................................................................................ 45 Figure 2.19 Activity diagram for search service.........................................................................................46 Figure 2.20 Activity diagram for Manage service...................................................................................... 47 Figure 2.21 Activity diagram for Make payment........................................................................................ 48 VII


Figure 2.22 Activity diagram for view service............................................................................................ 49 Figure 2.23 Collaboration diagram for Registration....................................................................................50 Figure 2.24 Collaboration diagram for Login..............................................................................................51 Figure 2.25 Collaboration diagram for Upload service............................................................................... 51 Figure 2.26 Collaboration diagram for Manage account............................................................................. 52 Figure 2.27 Collaboration diagram for View service.................................................................................. 52 Figure.2.28 Class diagram for the system ...................................................................................................53 Figure 2.29 User interface prototype for main menu...................................................................................55 Figure 2 .30 User interface prototype for vehicle post form .......................................................................55 Figure 2.32User interface prototype for service page .................................................................................55 Figure 3.1 Current software architecture..................................................................................................... 57 Figure 3.2 System architecture of Proposed system.................................................................................... 58 Figure 3.3 Three- tier architecture of proposed system............................................................................... 59 Figure 3.4 Sub-system Decomposition of Digital broker mobile application........................................... 60 Figure 3.5 Component diagram for Customer functionalities .................................................................... 61 Figure 3.7 Component diagram for Administrator functionalities.............................................................. 62 Figure 3.8 Deployment Diagram of Digital broker mobile application......................................................63 Figure 3.9 Persistent modeling for object oriented database....................................................................... 65

VIII


List of tables Table 1.0 Gantt chart for showing work break down.................................................................................. 11 Table 1.1 Use case documentation of Login................................................................................................22 Table 1.2 Use case documentation of registration....................................................................................... 23 Table 1.3 Use case descriptions for Create account.................................................................................... 24 Table 1.4 Use case documentation of Manage account...............................................................................25 Table 1.5 Use case documentation of delete service................................................................................... 26 Table 1.6 Use case documentation of send notification.............................................................................. 27 Table 1.7 Use case documentation of view service.................................................................................... 28 Table 1.8 Use case documentation of make payment..................................................................................29 Table 1.9 Use case documentation of post service...................................................................................... 30 Table 1.10 Use case documentation of send feedback................................................................................ 31 Table 1.11 Use case documentation of view feedback................................................................................ 32 Table 1.12 Use case documentation of search service.................................................................................33 Table 1.13 Use case documentation of Update profile................................................................................ 34 Table 1.14 Access control and security...................................................................................................... 66

IX

Abbreviations Table 1: Abbreviations

Digital Broker Mobile Application DBMA Object-Oriented Programming OOP Object Oriented System Analysis And OOSAD

Development Object Oriented Analysis

OOA Object Oriented Design OOD Hard Disk Drive HDD OOP

Object Oriented Programming

UML

Unified Modeling Language

SMS

Simple Message Service

Addis Ababa AA Data Flow Diagrams DFD

X


GUI

Graphical User Interface Class Responsibility Collaboration

CRC BR

Business Rule

XI

Digital Broker Mobile Application Table of Content

2017 GC.

Page no

Contact Information .................................................................................................................................... i Intellectual Property Declaration ..............................................................................................................ii Anti-Plagiarism Declaration .....................................................................................................................iii Acknowledgment ........................................................................................................................................iv Abstract ........................................................................................................................................................v List of figures ..............................................................................................................................................vi List of tables ………………………………………………………………………………………...…...viii Abbreviations ............................................................................................................................................. ix

Contact Information........................................................................................................................................... II Intellectual Property Declaration.................................................................................................................... III Anti-Plagiarism Declaration............................................................................................................................. IV CHAPTER ONE.................................................................................................................................................. 7 1

Introduction.................................................................................................................................................. 7 1.1

Background..................................................................................................................................... 8

1.2

Statement of problem.................................................................................................................... 8

1.1

Objective.......................................................................................................................................10 1.3.1 General objective:...................................................................................................................... 10 1.3.2 Specific objective:.......................................................................................................................10

1.2

Methodology................................................................................................................................ 11 1.4.1 Requirement gathering methods.............................................................................................. 11 1.4.2 Requirement modeling.............................................................................................................. 12

JIT, School of Computing Department of Computer Science

Page 1

Digital Broker Mobile Application

2017 GC.

1.4.3 System Analysis and design....................................................................................................... 13 1.4.4 Development Tools used........................................................................................................... 13 1.3

Feasibility study............................................................................................................................14 1.5.1 Economical feasibility................................................................................................................ 14 1.5.2 Technical feasibility....................................................................................................................15 1.5.3 Operational feasibility................................................................................................................15 1.5.4 Time feasibility........................................................................................................................... 15

1.4

Project scope and limitation........................................................................................................ 15 1.6.1 Scope of the project................................................................................................................... 15 1.6.2 Limitation of the project............................................................................................................ 16

1.5

Significance of the project............................................................................................................16

1.6

Project Work Plan.........................................................................................................................17 1.8.1 Gant chart................................................................................................................................... 17

1.7

Organization of the project..........................................................................................................18

CHAPTER TWO............................................................................................................................................... 19 2

System Analysis.......................................................................................................................................... 19 2.1

Existing system............................................................................................................................. 19 2.1.1 Existing system description........................................................................................................19

2.2

Existing system business rule.......................................................................................................20

2.3

Proposed System.......................................................................................................................... 21 2.3.1 Functional Requirements...........................................................................................................22 2.3.2 Non-functional requirements.................................................................................................... 23 2.3.3 Use case diagram........................................................................................................................25 Figure 2.5 Notation of extend relationship................................................................................ 26


Page 2


2017 GC.

Figure 2.6 Use case diagram of the system................................................................................ 27 2.3.4 Use case documentation...........................................................................................................28 Table 1.1 Use case documentation of Login...............................................................................28 Table 1.2 Use case documentation of registration.................................................................... 29 Table 1.3 Use case descriptions for Create an Account.............................................................30 Table 1.4 Use case documentation of Manage Account............................................................31 Table 1.5 Use case documentation of delete service................................................................ 32 Table 1.6 Use case documentation of send notification............................................................34 Table 1.7 Use case documentation of view service................................................................... 35 Table 1.8 Use case documentation of make payment...............................................................36 Table 1.9 Use case documentation of post service....................................................................37 Table 1.10 Use case documentation of send feedback..............................................................38 Table 1.11 Use case documentation of view feedback..............................................................39 Table 1.12 Use case documentation of search service.............................................................. 40 Table 1.13 Use case documentation of Update profile............................................................. 41 2.3.5 Sequence Diagram......................................................................................................................42 Fig.2.7 Sequence diagram for Broker login................................................................................ 42 Figure 2.8 Sequence diagram for view service...........................................................................43 Figure 2.9 Sequence diagram for post service........................................................................... 44 2.3.6 State chart diagram....................................................................................................................45 Figure 2.10 State chart diagram for Registration.......................................................................45 Figure 2.11 State chart diagram for Login.................................................................................. 46 Figure 2.12 State chart diagram for Post service....................................................................... 47


Page 3


2017 GC.

Figure 2.13 State chart diagram for View service...................................................................... 48 Figure 2.15 State chart diagram for Make payment..................................................................50 2.3.7 Activity Diagram......................................................................................................................... 51 Figure 2.16 Activity diagram for Customer registration............................................................ 51 Figure 2.17 Activity diagram for Login........................................................................................52 Figure 2.18 Activity diagram for post service.............................................................................53 Figure 2.19 Activity diagram for search service......................................................................... 54 Figure 2.20 Activity diagram for Manage account..................................................................... 55 Figure 2.21 Activity diagram for Make payment....................................................................... 56 Figure 2.22 Activity diagram for view service............................................................................ 57 2.3.8 Collaboration diagram............................................................................................................... 58 Figure 2.23 Collaboration diagram for Registration.................................................................. 58 Figure 2.24 Collaboration diagram for Login..............................................................................59 Figure 2.25 Collaboration diagram for Upload service.............................................................. 59 Figure 2.26 Collaboration diagram for Manage account........................................................... 60 2.3.9 Class diagram..............................................................................................................................61 Fig.2.28 Class diagram for the system........................................................................................ 61 2.3.10 User Interface prototyping...................................................................................................... 62 Figure 2.29 User interface prototype for Main menu. Figure 2.30 User interface prototype for Vehicle post form.................................................................................................63 CHAPTER THREE........................................................................................................................................... 64 3

System Design............................................................................................................................................. 64 3.1

Purpose and goal of design.......................................................................................................... 64

3.2

Current software architecture..................................................................................................... 65


Page 4


2017 GC.

Figure 3.1 Current software architecture...................................................................................65 3.3

Proposed software architecture.................................................................................................. 66 Figure 3.2 Proposed software architecture................................................................................67 Figure 3.3 Three- tier architecture of Proposed system............................................................ 67 3.3.1 Subsystem decomposition.........................................................................................................67 Figure 3.4 Sub-system Decomposition of Digital Broker mobile application......................... 69 3.3.2 Component diagram.................................................................................................................. 69 Figure 3.5 Component diagram for Customer functionalities...................................................69 Figure 3. 6 Component diagram for Broker functionalities.......................................................70 Figure 3.7 Component diagram for Administrator functionalities............................................70 3.3.3 Deployment diagram................................................................................................................. 71 3.3.4 Persistent modeling for object oriented database.................................................................. 72 Figure 3.9 Persistent modeling for object oriented database...................................................73 Figure 4.0 Database design......................................................................................................... 74 3.3.4 Access control and security........................................................................................................75 Table 1.10 Access control and security......................................................................................75

4.1 Implementation and Testing....................................................................................................................... 76 4.1.1 Objective of implementation.....................................................................................................76 4.1.2 Constraints on implementation.................................................................................................76 4.2 Testing....................................................................................................................................................76 4.2.1 Testing by Requirements........................................................................................................... 76 4.2.2 Testing the correctness:............................................................................................................. 77 4.2.3 Testing the Accuracy.................................................................................................................. 77


Page 5


2017 GC.

4.2.4 Testing the Performance............................................................................................................77 4.2.5 Testing the security.................................................................................................................... 77 4.2.6 Error Handling............................................................................................................................ 77 4.2.7 Testing by scope......................................................................................................................... 78 4.2.8 Unit testing................................................................................................................................. 79 4.2.9 Integration and system testing..................................................................................................79 4.3 Sample code and sample output screen.............................................................................................. 79 4.4. Installation..........................................................................................................................................113 4.5 Conclusion........................................................................................................................................... 113 4.6 Recommendation................................................................................................................................ 114 5.References...................................................................................................................................................... 115


Page 6


2017 GC.

CHAPTER ONE 1 Introduction This project is a mobile based brokering system for an existing broker service. It aims at replacing the manual brokering service into android system. Broker is the person who makes a contact between seller/renter and buyer, and then post the service information through the application. Digital brokering is the process whereby customers buy, rent and sell goods or services and also search for guards and house servants through online in real-time, over the Internet by using an android device. It is a form of electronic commerce. In this proposal, we aim at designing and implementing a remote digital brokering system and also improve brokering experience. This application comprises of three different subsystems. The first subsystem is implemented on customer’s mobile device. Through this application, customer can search for their need based on a particular location, vicinity, price and quality of the service or previous customer’s reviews. After choosing their need, customer can view a digital menu and select items by means of check boxes or any other means. The second subsystem is used by the service units. The user can view details of services. When a customer got his need, he/she completes his payment and all the information is sent to the central database. The third subsystem is used by the brokers of the system. Broker is sent notifications when a customer places an order; negotiate with the owner and makes payment to a particular service. Further, Broker can make all the transaction, if there has been a change in the quality, quantity, or prices.


Page 7

Digital Broker Mobile Application 1.1

2017 GC.

Background

Android application is a smart phone application that works on cell phones that uses an android operating system. In our county context, mobile phone users are increasing rapidly from year to year and even day to day but the mobile phone applications are in their developing stages so it is hard to find this application in the hands of an ordinary user. Because of their mobile platforms difference and internet applicability in our country most of mobile applications cannot reach or serve their purpose. Considering this point and other fields that need focus on development of Mobile application we have planned to develop this application that gives many significant services to its users, it embedded three applications within it that allows it to give 3 different services to its users, the services are: House sale and rent service  Vehicle sale and rent service

 Guards and servant online apply.

1.2

Statement of problem

Traditionally, to access their need, customer needs to directly interact with the broker or search by themselves. Further, customer needs to have a direct contact with the owner and the services they provide whether or not it satisfies their need. However, today’s era is witnessing people engaged in something or the other all the time. Customers are also demanding simplification of tasks in almost every field, from shopping to buying cars to booking movie tickets, cabs, etc. While searching for need, certain obvious inconveniences are faced by regular customers. These inconveniences include waiting, discrepancies in the need, time consuming and so on. Currently, most of commodity seekers search for their needs such as house, vehicle, guards and servants though a manual means of searching. This way of finding need consumes, time and budget of customers and brokers. And also it is quite difficult to get their need of interest.


Page 8


2017 GC.

In addition to this, facilities seekers view and search for the service through some web-based applications such as betoch.net and makina.net through online but these sites are used with the help of web browser to visit the site and perform their own applications Generally the current system has the following problems: Consumes time and budget of commodity seekers:-commodity seekers spend a lot of time and budget in searching for their need. Problem in finding renter or buyer:-Since they do manually it’s difficult for the broker to know whether the previously informed service is rented/sold. Conflicts:-since there are a lot of brokers in the traditional way, each of them informing different user and a single service may be tried to be accessed by many users which may result in conflict between users. Every time user needs to connect brokers manually by either going to his office or home. Most of the times user should want to wait in queue:-since there are a lot of customers that need for the service and they may come at the same time which may result in the user’s being wait in queue. Users can’t get their need easily. It takes long period of time to satisfy user need:-customer may tell his need to the broker and it may take a long period of time for the broker to satisfy user need.

It is difficult to know whether the provided information is true or not:-the owner of the service may tell false information about his service to the broker. Hence, it became imperative to develop a mobile based brokering system to eliminate the shortcoming of the manual system as above listed problem.


Page 9


2017 GC.

Objective

1.3.1 General objective: The general objective of this project is to design and implement a digital brokering system for Addis Ababa city.

1.3.2 Specific objective: The specific objective of this project includes:  Creating a system that can guide customer by providing some detail information of services including their location.  Perform requirement analysis.  Find a solution to the existing problem.  Design the architecture for the proposed system.  Develop user friendly and interactive system.  To develop easy way of registering form for user, house and vehicle information.  To transform the manual process of renting and selling of vehicle and house in Addis Ababa city to a mobile system.  Design persistent database.  Implementing mobile application and acquiring a new knowledge.  Test the developed system.  Deploy the system.  Lay concrete on a way to proposal in the area of android mobile applications in JU (Jimma University) so that other students can have foundation on which they can add more advanced functionalities on the system.


Page 10


2017 GC.

Methodology

Methodology deals with a system of ways used in gathering information, analyze and design implement, test and evaluate the system. Most used methodologies are prototyping, iterative, incremental, waterfall, agile, etc. Among them we select agile development methodology for our system. The requirements for agile development are requirement gathering, analysis and design, coding, testing and acceptance. The advantage of agile development method is incremental (multiple releases), cooperative (a strong cooperation between developer and client), straightforward (easy to understand and modify) and adaptive (allowing for frequent changes).

1.4.1 Requirement gathering methods To develop our application the primary task is understand more about the current brokering system being used; we gathered different information from web based broker applications like betoch.net and also we have gathered data using the following techniques. 

Interview: We ask some peoples directly and using phone about the current system and the techniques used in the system. We made a face talk with traditional broker about the system some of which are: How the communication takes place between the broker and the owner? What type of services does the broker provide? What type of information does the broker should have to know about the services? What is the quality criteria for a person to be a broker and etc..



Observation:We have observed the traditional means of brokering system when the service seekers waste their time searching for their need and the brokers too by moving from place to place.



Introspection: all group members will discuss together about the requirements.


Page 11


2017 GC.

 Brainstorming: since the project will be done in group, every group member will provide their idea on the requirements. 

Web analysis: additional information will be gathered from websites concerning the current system.

1.4.2 Requirement modeling Analysis and design the system using object oriented approach. We need a method for analyzing a problem to be solved, a plan for the design of the solution and a construction method that minimizes the risk of error. We have chosen the object oriented approach (OO) to follow for our proposed system. Object-oriented programming (OOP) is an approach to designing modular reusable software systems. A module is a component of a larger system that interacts with the rest of the system in a simple and well-defined manner. The object –oriented approach is a logical extension of structured programming, module containing data and subroutines. An object is a kind of self –sufficient entity that has an internal state (the data it contains) and that can respond to messages (call to its subroutines). We select object-oriented programming because it produces solutions that are easier to write.

 Easier to understand  Contain fewer errors  Reduction of development time  Reduction of time and resources required to maintain existing systems  Increase code reuse.


Page 12


2017 GC.

1.4.3 System Analysis and design We use OOSAD (Object oriented system analysis and development) during the whole project life cycle. In our project, we will apply the concept of object oriented system development methodology which categorized in to two phases. These phases are object oriented analysis and object oriented design. It increases consistency among analyzer, designer implementation and testing. It also allows the reusability of the code which will help to enhance the project in the future. We consider following object oriented system has many benefits over structured approach:  It is easier to develop and maintain.  It is reusability, extensibility, improves quality, maintainability and manages complexity.  The transition from Object Oriented Analysis (OOA) to Object Oriented Design (OOD) can be done easily because of OOA is resilient to changes as objects are more stable. In general we will use this object oriented methodology for the following purposes; Simplicity, Maintainable, Faster Development, Increased Quality.

1.4.4 Development Tools used Software and hardware tools are necessary for the development and deployment of the project. The following tools are used to develop the proposed system:  Hardware tools: Desktop computer/laptop. Displaying devices like monitor. Storage devices: hard disk, flash disc. Internet cable. Processor: Any processor. RAM: Minimum of 2 GB (In order the system to run faster). 60 GB of Hard Disk Drive (HDD). Internal modem Software. Internal NIC (Network Interface Card).  Software tools: Microsoft word 2016:-for preparing documentation proposal.


Page 13


2017 GC.

Microsoft PowerPoint:-for preparing presentation slides. Eclipse:-is an android environment/workspace for coding. Android OS:-is a software platform that supports android application. MYSQL /XAMPP server:-is a server on which data is stored and retrieved from. Notepad++:-is an environment for writing HTML/PHP codes. EDrawMax:-is software used for designing and drawing UML diagrams (use case diagram, sequence diagram, class diagram, activity diagram, state chart diagram, component diagram, and deployment diagram). Web browser:-is used for browsing HTML file and data from server.

1.3

Feasibility study

A feasibility study decides whether or not the proposed system is worthwhile in different dimensions. It measures how much the proposed system is beneficial or practical at development of the system. The feasibility factors of our project are:  Economic feasibility  Operational feasibility  Technical feasibility  Time feasibility

1.5.1 Economical feasibility Economic feasibility attempts to weigh the costs of developing and implementing a new system, against the benefits that would accrue from having the new system in place. This feasibility study outlines the economic justification for the new system. It gives the actual comparison of costs and benefits are much more meaningful in this case. Since this type of Application’s are new in our country in that it supports a lot of services, the people acceptance toward this system will be high and also there will be very less computation in the market due to this reason's and other causes the project


Page 14


2017 GC.

benefits will outweigh the expected cost. But Since the Application is free for users the agencies only get benefit (income) from advertisement of those services that are included in the application.

1.5.2 Technical feasibility We believe that building a working system with acceptable characteristics, response time and other performance parameter will involve through technical knowledge and technology availability.

1.5.3 Operational feasibility Measure how much the proposed system solves the existing system problems. This project is surely operationally feasible because the proposed system (the project) is a good solution maker of the problem and create a good environment towards the user of our application by providing easy, user interactive, everywhere and anytime accessible.

1.5.4 Time feasibility Time feasibility determines whether the proposed system will be completed on the given schedule or not. Whatever the scarcity of time given for the project by the internal motivation and potential of the team members of the project, we expect the project will be completed on time that is described under the project work plan below.

1.4

Project scope and limitation

1.6.1 Scope of the project The system focus on mobile based brokering system which will cover only in Addis Ababa city and will perform the following activities: Registration of user: the proposed system will register full information of the user. Registration of services:-The proposed system will registers all service information. 

Registration of House.



Registration of Vehicle.



Registration of guards and house servant.

Update Service information: It updates the service information when needed. Search for services: To search for the service that the customers need.


Page 15


2017 GC.

Notification:-notifying the broker and the owner when the need request is sent by the service seeker.

1.6.2 Limitation of the project This project covers some of the aspects of brokering agency as case study. However the following are the constraints:Time constraints: - Due to time constrain the system covers only for managing and controlling AA brokering Agency. Generally the limitation of this project includes:  This project done only for AA city.  The system can’t work unless there is an internet connection.  The system will only run on android platform.

1.5

Significance of the project

The main purpose of this project is to develop a mobile application which enables easy way of searching a service that match their need in an easy, cost effective and timely manner .That means it enables the customers to search and access their need through their mobile anywhere any time. In general, the system has the following benefits: 

Minimize the time and resource required to get the service.



Easy data storage and management.



Reducing the probability of errors.



Potentially increasing data security and confidentiality.



The app runs on android device so as it’s every time everywhere accessible (usage of portable device).


Page 16

Digital Broker Mobile Application 

2017 GC.

Effectively and efficiently manage and control of information about users, House, Vehicle, guards and house servants.



User can find sellers contact details.



Buyers can communicate with sellers by making call or message directly by using application.

In general this system will reduce the cost, time, and effort of the user and also it will provide such an easy way to use.

1.6

Project Work Plan

1.8.1 Gant chart The project is officially started on 25/02/2009EC and will be completed on 26/09/2009 EC.

26/09/2009

25/09/2009.

4/09/2009-

3/09/2009.

1/07/2009-

20/06/2009.

01/05/2009-

30/04/2009

11/04/2009-

10/03/2009

Activities

25/02/2009-

Time

Proposal Requirement Analysis Design Implementation &coding Testing Project Defense/Demonstration Table 1.0 Gantt chart for showing work break down


Page 17


1.7

2017 GC.

Organization of the project

The project is organized in five chapters. The first chapter is about the problem identification having background of the project, statement of problems, objectives and scope and limitations. The second chapter deals with the overall system analysis, work of the current system and view of the proposed system as well as diagrams i.e. Use Cases are written along their documentation. Sequence diagrams, activity diagrams are used to analyses the system. The third chapter is about the system design. Deployment and component diagrams are used to show the solution design. The implementation part is on chapter four. And finally chapter five deals about testing and evaluation mechanisms


Page 18


2017 GC.

CHAPTER TWO 2 System Analysis

2.1

Existing system

There are many websites that connect customer with service. Among these betoch.net and makina.net are some of them. The site betoch.net is an online house buy, sell and rental service provider.Makina.net is also an online site that provides car rental and sale services. Even though these applications are developed for providing services we are aimed to do on, their scopes are very few. For instance the website betoch.net gives information about house only. The same is too for makina.net which provides information regarding car rental and sale. They are all web based and require a working and installation of web browsers on your system. Each service provider has its own websites by the current advanced system. This and other combine together and push us to develop an android based application which provides the more general service including guards and house servants.

2.1.1 Existing system description Most of the systems we are going to develop are not in work in the current system i.e. no system is developed for it so we can’t find this service in mobile frames or web too. So users are using the following methods to use the services we are going to build: 1. To get the service of House and Vehicle either for rent/sale  Open a web browser on his device.i.e need to have a working installation of web browser.  Browse the site i.e. Betoch.net for house and Mekina.net for car service.  The site don’t care about what is posted i.e. no persistence check of the information posted is carried out by the system.  To access the service, payment will take place through online means. Apart from this all, the services are posted by the user themselves. The user can post everything he went which may be for fake, and even if real he may include additional information that his service


Page 19


2017 GC.

doesn’t have. Through the current system there is no way to check for this information. Thus this may result in the user being bored with system.

2.2

Existing system business rule

A business rule is an effectively operating principle or polices that we try to specify for both the existing system and the new system must satisfy. The business rule is a principle or a policy in which the proposed system operates accordingly. It deals with access control issues.It often pertains to access control issues, operating policies and principles of the organization. The organization has the following principles in the existing system which includes: BR1: The existing system only provides a specific service while our system contain 4 services together. BR2: The customer should have to register. BR3:The user should fill the form properly. BR4: Only the customers who have a valid login can get access to the service. BR5: The customer should have to fill their bank account number to get access to the service. BR6:The system should work 24 hours, when there is an internet access. BR7:The system should secure the way the service is accessed. BR8: The system should update the information when there is change in the information. BR9:The system should automatically delete the service and it’s information from database when it’s accessed by any customer. BR10:The system should reduce from the customer’s bank account/balance when he wants to access service.


Page 20


2017 GC.

Alternate solution The problems we explained above makes the existing system hard to use for users because the services we are going to be built cannot be found in one place, users have to search different places to use the services The best alternative solution to solve the problems described above is to change the system by a new system that the user can get these four services in one place in their mobile phone without going and searching different places and also making the services available for free.

2.3

Proposed System

Digital broker is a server based mobile application. This application contains server side containing the database of the services, customer and broker; and a client side containing GUI (graphical user interface).And our system will also have detailed information about the services (house, vehicle, guards and house servants). This system enables customer to search and view details of their need posted by the broker and will generate and forward announcement and the need notifications for the owner. It wills also shortlist the currently available needs. This provides customers with a very interactive experience with the application. Customers are given the facility to register themselves. Upon registering, the customer gets to have a profile of his own and also provide feedback. An additional feature that we have included in the customer’s application is that two or more customers can place order from remote locations. This application helps seekers to view and search for their need by accessing it through mobile without the need for moving physically from broker to broker, installation of web browser and remembering the domain name of the website.


Page 21


2017 GC.

2.3.1 Functional Requirements The Functional Requirements Specification specifies the operations and activities that a system must be able to perform. Functional requirements should include functions performed by specific screens, outlines of work flows performed by the system, and other business requirements the system must meet.  Administrator 

Registering brokers (Create account).



Manage brokers (Update and delete brokers account).



View report.



Update his profile.



Post service information.



View service information.



Update service information.



Delete service information.



Generate report.



View notifications.



Send notifications



View user feedback.



Search Service.

 Broker


Page 22


2017 GC.

 Customer 

Register.



View services.



View notification.



Send feedback.



Order existing service.



Make call.



Make payment.

2.3.2 Non-functional requirements Non-functional requirement is a requirement that specifies criteria that can be used to judge the operation of a system, this requirement does not directly affect the performance of the proposed system but, they concerned with security, performance, usability, maintainability,

reliability,

efficiency, portability (across operating systems) testability, understand ability etc.The nonfunctional requirements of the system are presented below: -

♠

User Interface: - users require the interface to be attractive and user-friendly with easy navigational scheme.

♠

Security issue:

-

provides security tasks such as for registering, for modifying user’s

information and viewing needs authentication and authority.

♠

Maintainability: - When the system fails, it can be maintained easily.


Page 23

Digital Broker Mobile Application ♠

2017 GC.

Performance: - the performance of our system is measured in terms of load time and number of requests handled. So it is fast in accepting inputs and displays the result as well as requires small space.

♠

Error handling Mechanism: - handles invalid inputs and display user error in meaningful messages.

♠

Availability: - The system will be available for 24 hours to users with internet connection.

♠

System requirement:-Our system requires software and hardware requirements. These are:A) Hardware requirement Flash 16 GB Laptop RAM size 4 GB or more Processor speed 2.5 GHZ or more B) Software requirement Notepad ++ XAMP Server Edraw Max Mozilla Firefox, Baidu browser Microsoft office word 2016

♠

Backup and Recovery: - The system should store a backup database daily the system may face some errors on the data base server.

♠

Others ►

Internet connection.

►

Dedicated lab room.


Page 24


2017 GC.

2.3.3 Use case diagram A use case is a sequence of action that provides a measurable value to an actor. a. Use case components:  Actor: is a person, or external system that plays a role in one or more interaction with the system. And represented with:

Figure 2.1 actor notation

 Use case: describes a sequence of actions that provides something of measurable value to an actor and is drawn as a horizontal.

 Horizontal ellipse.

Figure 2.2 use case notation

 System boundary: indicates the scope of the system project. Anything within the box represent functionalities in side in scope.

Figure 2.3 Notation for system boundary


Page 25


2017 GC.

 Include Relationship: A part of use case which appears in the same identical form in other use cases may be transferred to its own use case and re-integrated universally via an Include relationship in order to avoid the redundant specification of these identical parts.

Figure 2.4 Notation of include relationship

 Extend Relationship: The Extend relationship points to the use case to be extended, and starts from that use case which describes the extension's behavior.

Figure 2.5 Notation of extend relationship

Actor description Customer: -a Person who wants to see information of service and can get access of the service. Admin:-is the person who is in charge of managing and administering the system. He manages the system access right for others. Register brokers and manage their accounts. Broker: -an actor that posts the service information and can made any transaction on them. He have role of a supervisor in the sense that he controls the sites, enter new service information, update information, delete information, search information’s and can read user feed backs.


Page 26


2017 GC.

Figure 2.6 Use case diagram of the system.


Page 27


2017 GC.

2.3.4 Use case documentation

Table 1.1 Use case documentation of Login Use case name

Login

Use case number

Uc#1

Actor(s)

Broker,Customer,Admin

Description

Helps to control the system from unauthorized persons to access the system

Typical course action

Actors action:

System response:

Step1.The actor click on login Step2. The login page displayed. button. Step5.The system verifies the authority. Step3.The actor enters user name and password.

Step6. The system displays the actors page. Step8. The use case ends.

Step4.The user click login button

Alternate course of action

Step7.If the actor enters invalid user name or password, the system displays error message and goes to step 3.

Pre-condition:

The actor must be registered first and the list must be found in the database.

Post-condition:

The actor can do anything in the main page with his/her privileges.


Page 28


2017 GC.

Table 1.2 Use case documentation of registration Use case name

Register

Use case number

Uc#2

Actor(s)

Customer

Description

Helps to register the customer for accessing the services.


Actors action: Step1.The

System response:

customer

wants

register himself to access services.

to Step2:The system displays registration

page.

Step5:The system validates whether the the information submitted is correct or not. necessary information in to the Step7:The system registers and displays Step3:The

user

enters

form in the registration page.

registration successful message and leads

Step4:The user clicks on register to home page. button. Step8:The use case ends


Step6.If the entered information is not valid the system displays an error message and goes to step 3.

Pre-condition:

The customer must fulfill whatever required information like bank account number, phone number etc…

Post-condition:

The customer can easily access the service by login to the system.


Page 29


2017 GC.

Table 1.3 Use case descriptions for Create an Account.

Use case name

Create Account

Use case number

Uc#3 Admin

Actor(s)

The admin creates an account for brokers so as they can manage the

Description

services.

Typical course of action:

Actor Action

System Response

Step1:This use case is initiated Step2:The system displays the create when the actors clicks on the account page. create account option Step3:The

actor

Step4:The enter

checks

the

the information is correct or not.

required information.

Alternative course of action:

systems

Step6:Use case ends.

Step5:If the actor does not fill the required information then the system display error message and return to step 3.

Pre-condition:

The Actor must have a privilege to create an account.

Post-condition:

The Actors should create account.


Page 30


2017 GC.

Table 1.4 Use case documentation of Manage Account

Use case name

Manage Account

Use case number

Uc#4

Actor(s)

Administrator

Description

Helps to create, delete, and deny user account for users of the system and sets privilege to them.


Actors action:

System response:

Step1.The administrator wants Step2.The system includes login

to update Account of a user

page.

Step4.The administrator clicks Step3.The

on manage account button.

system

displays

an

displays

the

account page.

Step6.The administrator selects Step5.The

system

a user/broker, for whom to users/brokers account page. manage account. Step8.The system verifies validity Step7.The administrator then update/delete the users/brokers

of the brokers information and response with success message.

account by inserting necessary information.

Step10.Use case ends.


Page 31


2017 GC.

Alternate course of Step9.If the entered incorrect information while updating, the system action

displays an error message and goes to step7.

Pre-condition:

The Administrator must have a privilege to login.

Post-condition:

The Administrator will update/delete user/brokers account.

Table 1.5 Use case documentation of delete service

Use case name

Delete service

Use case number

Uc#5

Actor(s)

Broker

Description

The broker can delete any service at a time when he wants.


Actors action: Step1.The

broker

System response: wants

to Step3.The system displays the brokers

delete service information from page. the system. Step2.The broker login to his Step5.The page. Step4.The

system

displays

the

available services. broker

clicks

service button.

on Step7.The system displays a pop-up

Step6.The broker clicks on the menu asking you want to delete? service he want to delete.

Query.

Step8.The broker clicks on OK Step10.The use case ends. button.


Page 32

Digital Broker Mobile Application Alternate course of action

2017 GC.

Step9.If the broker clicks on cancel button the system will go back to step5 .

Pre-condition:

The broker must have a privilege to login.

Post-condition:

The broker successfully delete service from the system and the service will not be accessible forward.


Page 33


2017 GC.

Table 1.6 Use case documentation of send notification

Use case name

Send notification

Use case number

Uc#6

Actor(s)

Broker,customer

Description

The actors can send notification to whom they want to.


Actors action:

System response:

Step1.The actor wants to send Step3.The system displays the actors

notification.

page.

Step2.The actor login to his page.

Step5.The

system

displays

the

Step4.The actor clicks on send notification page.

notification button.

Step7.The

system

displays

Step6.The actor clicks on OK successfully sent message. button. Alternate course of action

Step8.The use case ends.

Step9.If the actor clicks on cancel button the system will go back to step3 .

Pre-condition:

The actor must have a privilege to login.

Post-condition:

The actor successfully send notification to whom he want to send.


Page 34


2017 GC.

Table 1.7 Use case documentation of view service

Use case name

View service

Use case number

Uc#7

Actor(s)

Broker,customer

Description

The actors can view the service he want to see and get access to.


Actors action:

System response:

Step1.The actor wants to view Step3.The

system

displays

the

the service.

homepage.

Step2.The actor visit the site.

Step5.The system displays the service page.

Step4.The actor clicks on the

service he want to view. Step6.The

actor

views

Step7.The use case ends. the

services. Alternate course of action

Step8.

Pre-condition:

The actor must have application installed on his device.

Post-condition:

The actor views the service.


Page 35


2017 GC.

Table 1.8 Use case documentation of make payment

Use case name

Make payment

Use case number

Uc#8

Actor(s)

Customer

Description

The customer makes a payment to get access to the service he wants.


Actors action:

System response:

Step1. The actor wants to get Step3.The

the service.

homepage.

Step2.The actors visit the site.

Step5.The

system

displays

the

system

displays

the

service page. Step4.The actor clicks on the Step8.The

service he want to view.

system

automatically

displays a pop-up having a ‘need requests button.

Step6.The

actor

views

the Step10.The

services.

system

automatically

reduces the amount that the service

Step7.The actor clicks on the costs from the customer’s account service he wants to get access.

number. Step12.Use case ends.

Step9.The actor clicks on the ‘need requests button.


Step11.If the user doesn’t have enough account in his bank system, the system automatically sends an error message saying “you don’t have enough balance in your account!”.


Page 36


2017 GC.

Pre-condition:

The customer must login to the system.

Post-condition:

The customer makes payment and gets access to the service.

Table 1.9 Use case documentation of post service Use case name

Post service

Use case number

Uc#9

Actor(s)

Broker

Description

Broker uploads lists of services to the database.


Actors action:

System response:

Step1.A broker wants to upload Step3: The system displays add new service.

service form. Step5:The system validates the data

Step2: The actor selects the entered post service option. Step6: The system registers and displays Step4: A broker enters the registration success message and leads to necessary information in to home page. the form.


Step8:The use case ends

Step7: If the entered information is not valid the system displays an error message and goes to step 4.

Pre-condition:

Broker must login into the system to post services.

Post-condition:

The broker can upload services for Customers.


Page 37


2017 GC.

Table 1.10 Use case documentation of send feedback Use case name

Send feedback

Use case number

Uc#10

Actor(s)

Customer

Description

Helps customer to send feedback about the service to brokers.


Actors action:

System response:

Step3: The system displays the form on Step1.A customer wants to send witch feedback is given. feedback. Step5: The system sends feedback to

the broker. Step2: The actor clicks on the


send feedback button. Step4:

A

customer

writes

his/her comment about the service in to the form.

Alternate course of action Pre-condition:

Customer must login into the system to give comment.

Post-condition:

The customer sends comment to the broker.


Page 38


2017 GC.

Table 1.11 Use case documentation of view feedback Use case name

View feedback

Use case number

Uc#11

Actor(s)

Broker

Description

Helps broker to view feedback that is sent from customers.


Actors action:

System response:

Step3: The system displays feedback Step1.A broker wants to view that is given. feedback. Step4: The system sends feedback to

the broker. Step2: The actor clicks on the


view feedback button. Alternate course of action Pre-condition:

Broker must login into the system to view comment.

Post-condition:

The broker views feedback given.


Page 39


2017 GC.

Table 1.12 Use case documentation of search service Use case name

Search service

Use case number

Uc#12

Actor(s)

Customer, Broker

Description

Helps customers to search the service that he need.


Actors action:

System response:

Step3: The system displays different Step1.A customer and wants to search options for services. search for service. Step5: The system checks search result

in the database display to the customer Step2: customer clicks on search service button. Step4:A

customer

or broker. Step7:The use case ends

selects

search option Alternate course of action

Step6: If the search result is not in the database the system displays the message that notify search result does not exist and goes to step 4.

Pre-condition: Post-condition:

The customer can get services.


Page 40


2017 GC.

Table 1.13 Use case documentation of Update profile

Use case name

Update profile

Use case number

Uc#13

Actor(s)

Broker

Description

Helps broker to personalize his/her account details.


Actors action:

System response:

Step2: The system displays the form of Step1.Brokers want to update profile. his/her details. Step5:

The

system

validates

the

information entered. Step3: The actor selects the update profile option. Step4: A broker enters the

Step6: The system updates information in database and displays success message. Step8:The use case ends

necessary information to be updated.


Step7:If provided information is not valid the system displays an error message and goes to step 4.

Pre-condition:

Broker must login into the system to update his/her own profile.

Post-condition:

Broker can easily update necessary information about his/her.


Page 41


2017 GC.

2.3.5 Sequence Diagram Sequence diagrams are dynamic model of use cases, showing the interaction among classes during a specified time period. Sequence diagrams graphically document the use case by showing the classes, the messages, & the timing of the messages. A sequence diagram in our system is used to formalize the behavior of the system and to visualize the communication among objects. It helped us to identify additional objects and participate in the use case. This phase of the document ties use cases with objects and shows the behavior of a use case is distributed among its participating objects.

Fig.2.7 Sequence diagram for Broker login


Page 42


2017 GC.

Figure 2.8 Sequence diagram for view service


Page 43


Figure 2.9 Sequence diagram for post service


2017 GC.

Page 44


2017 GC.

2.3.6 State chart diagram State chart diagram is used to describe the states of different objects in its life cycle. States can be identified as the condition of objects when a particular event occurs.

Figure 2.10 State chart diagram for Registration


Page 45


2017 GC.

Figure 2.11 State chart diagram for Login


Page 46


2017 GC.

Figure 2.12 State chart diagram for Post service


Page 47


2017 GC.

Figure 2.13 State chart diagram for View service


Page 48



2017 GC.

Page 49


2017 GC.

Figure 2.15 State chart diagram for Make payment


Page 50


2017 GC.

2.3.7 Activity Diagram Is one of the components of UML. It highlights the activities performed in the system. Each activity is represented by a narrow and more oval shape. They are used to document the logic of a single operation/method, a single use case, or flow of logic of business operation. They are the object oriented equivalent of flow charts and data flow diagrams (DFD) from structured development. This part of the project documentation consists of an activity diagram that shows the flow of action in main use cases.

Figure 2.16 Activity diagram for Customer registration.


Page 51


2017 GC.

Figure 2.17 Activity diagram for Login


Page 52


2017 GC.

Figure 2.18 Activity diagram for post service


Page 53


2017 GC.

Figure 2.19 Activity diagram for search service


Page 54


2017 GC.

Figure 2.20 Activity diagram for Manage account.


Page 55


2017 GC.

Figure 2.21 Activity diagram for Make payment


Page 56


2017 GC.

Figure 2.22 Activity diagram for view service


Page 57


2017 GC.

2.3.8 Collaboration diagram Collaborative diagram emphasizes the context and the overall organization of the objects that interact. It shows the message the object sends in addition to the association among objects.A label near the arrow shows what the message is. The message typically tells the receiving object to execute one of its operations.

Figure 2.23 Collaboration diagram for Registration


Page 58


2017 GC.

Figure 2.24 Collaboration diagram for Login

Figure 2.25 Collaboration diagram for Upload service


Page 59


2017 GC.

Figure 2.26 Collaboration diagram for Manage account

Figur e 2.27 Collaboration diagram for View service


Page 60


2017 GC.

2.3.9 Class diagram UML class diagram shows the classes of the system, their interrelationships (including inheritance, aggregation, and association), and the operation and attributes of the class. It shows the static structure of the model, in particular, the things that exist (such as classes and types), their internal structure, and their relationships to other things. This project used class diagram to design the structures that will be included in the system and the things that will be exist in the system.

Fig.2.28 Class diagram for the system


Page 61


2017 GC.

2.3.10 User Interface prototyping Digital broker Mobile application system has easy and user friendly user interfaces. This application contains server side containing the database of the services, customer and broker (web application user interface); and a client side containing GUI (graphical user interface).


Page 62


Figure 2.29 User interface prototype for Main menu.

2017 GC.

Figure 2.30 User interface prototype for Vehicle post form.

Figure 2.32User interface prototype for Service page.


Page 63


2017 GC.

CHAPTER THREE 3 System Design

3.1

Purpose and goal of design

The purpose and design goal of the system is to provide a solution for problems that are listed on the analysis phase. The design goal can be inferred from non-functional requirements which will be discussed as follows:  User-friendly: the system should be easy to learn, understand and operate. It should provide interactive and easy interfaces which can allow unprofessional users to deal with it. Current software architecture .  Performance: the system need to have maximum throughput at minimum time to allow many users to access concurrently, and it should not take much space to be installed on users’ cell phones.  Maintainability: the application should be easily scalable and extensible to add new features. And also it should be easily modifiable to make changes on the functionalities.

The

maintainability of the system includes:  Perfective: adding new functionalities or changes to the system.  Corrective: fixing errors on the system.  Preventive: increase systems maintainability and reliability.  Usability: can be seen in two ways.  Effectiveness: the system should provide services which help the user to achieve their goal.  Efficiency: the users should spend minimum effort and resource to achieve their goal.


Page 64


2017 GC.

 Reliability: the system should maintain and perform its functionalities under any condition. It should have minimum frequency of failure and adaptable for failures.  Security: The system should allow login to only authorized users. i.e. users that have previously created account through user name and password. 

Accuracy:The system should give only valid result, if no data is found with the specified criteria the system should not give invalid response.

3.2

Current software architecture

As we described in chapter two, there are some web based systems that are similar to our proposed system but our system have some additional features. But still they all share similar architecture except ours also include an android application in the client side. The architecture of the current web based system is as follows.

Figure 3.1 Current software architecture


Page 65


2017 GC.

Proposed software architecture

In this section we design the conceptual model of the Digital Broker Mobile Application. Here there are Customers who use this system on their cell phone to get different services of the system. They can view, search and Register themselves; Once they are registered they can get services by logging into the system. There are also Brokers who Posts different services ,manage the services that are posted and can also view customer’s feedback. There are also Administrator that create accounts for Brokers ,manage Brokers account and also view brokers report. The proposed software has three- tier architecture.  The presentation tier: is the top most level of the application. It is the one the clients directly interacted. It provides GUI to allow the client gaining access of the system.  Logical tier/ middle tier: It accepts inputs from the client and performs detailed processing. It is a bridge between data access tier and presentation tier.  Data access tier: provides data persistence mechanism and storage to the data. It consists of a mechanism to access the database without installing data base dependent drivers and libraries on the client device.


Page 66


2017 GC.

Figure 3.2 Proposed software architecture.

Figure 3.3 Three- tier architecture of Proposed system.

3.3.1 Subsystem decomposition Subsystem decomposition is the process of separating out a module into a standalone module in and of itself. It makes the system easy to understand, design, develop and maintain.The major subsystems of Digital broker Mobile Application are login, Create account, account management, Service management, report generating, view report, feedback sending, upload services,view Notification, send notification. 

Login: Perform authentication of the user to interact with the system.



Manage account: allows the administrator to update and delete Broker’s account.



Generate Report: allows the Brokers to generate reports.



Registration: allows customers to register the selves .


Page 67


2017 GC.



Post service: allows Broker to upload service information to the server.



View Service: allows Broker, or customer to see services that are posted.



Order Service: Helps customer to order existing services whenever the he/she wants to get the service.



Make call: helps the customer to make call when he/she wants to contact the broker.



Send notification: notification is sent to broker and owner when customer clicks on need service button.



Make payment: checks customer’s bank account and the system automatically reduces the amount that the service costs from the customer’s account number.


Page 68


2017 GC.

Figure 3.4 Sub-system Decomposition of Digital Broker mobile application.

3.3.2 Component diagram The component diagram helps to model the physical aspect of an object-oriented software system. It illustrates the architectures of the software components and the dependence between them.

Figure 3.5 Component diagram for Customer functionalities


Page 69


2017 GC.

Figure 3. 6 Component diagram for Broker functionalities

Figure 3.7 Component diagram for Administrator functionalities


Page 70


2017 GC.

3.3.3 Deployment diagram The deployment diagram specifies a set of constructs that can be used to define the execution architecture of systems that represent the assignment of software artifacts to nodes. Nodes are connected through communication paths to create network systems of arbitrary complexity. Nodes are typically defined in a nested manner, and represent either hardware devices or software execution environments.

Figure 3.8 Deployment Diagram of Digital broker mobile application


Page 71


2017 GC.

3.3.4 Persistent modeling for object oriented database This modeling used to depicts the design of the database. The persistent classes are used to store most important and permanent in formation of the system. In persistent modeling the team member will perform the following activities. 

Identifying entities



Identifying keys



The methods of classes



Data type and size.


Page 72


2017 GC.

Figure 3.9 Persistent modeling for object oriented database


Page 73


2017 GC.

Figure 4.0 Database design


Page 74


2017 GC.

3.3.4 Access control and security Here we will describe the privileges or authorities of actors over the functionalities. In this system there are three actors Broker, Customer and Administrator. Each has their own privileges to gain access of the system.

Customer Login

Broker

Admin





Update profile



Post services







Manage service View Notification





Send notification





Register



Create account



Manage account

 

View feedback Send feedback



Make call



Order service



Search service



Make payment





Table 1.10 Access control and security


Page 75


2017 GC.

4.1 Implementation and Testing 4.1.1 Objective of implementation The objective of our implementation is to develop Digital Broker Mobile Application for Addis Ababa city with high efficiency, error free and high quality service .

4.1.2 Constraints on implementation This section should contain an exhaustive list of constraints that may have an impact on Digital Broker Mobile Application. Protocol warning: Server version mismatch. Resources: the resources we have used for implementation phase is not very efficient to support the programming environment. Protocol error: Protocol version mismatch. Time constraint:Due to shortage of time we did not included all the validations and some functionality. Project complexity:Since our project includes four subcomponents(Vehicle,House,Guard and House Servant) integrated into it,it become tough enough to made it fully functional.

4.2 Testing 4.2.1 Testing by Requirements Before the system can be delivered, it must be thoroughly tested. System need to be tested to ensure that it satisfies the user requirements accurately and completely. Individual components are tested independently, and then are tested together as a sub-system and then the sub-systems are tested together as a whole system. Also can perform some form of acceptance testing before the system is finally accepted and complete.


Page 76


2017 GC.

Testing can be stated as the process of validating and verifying that a computer program/application can: meets the requirements that guided its design and development, works as expected, can be implemented with the same characteristics, and satisfies the needs of users. The requirement are tested during the implementation are correctness, performance, accuracy, security and others.

4.2.2 Testing the correctness: Correctness determines how users can interact with the software and how the software should behave when it is used correctly. Users can easily interact with the application since it has easily understandable interface and the application responds correctly. This makes our system (Digital Broker Mobile Application ) correct.

4.2.3 Testing the Accuracy The system give only valid result, if no data is found with the specified criteria the system should give valid response. Since, our application fulfills these characteristic it is accurate.

4.2.4 Testing the Performance Performance testing measures the quality attributes of the system, such as scalability, reliability and resource usage. In our system we use efficient algorithms for each task which will make it fast and require less storage. As a result our application (Digital Broker Mobile Application system) has high performance; since, it executes the required task output within few seconds.

4.2.5 Testing the security The security of Digital Broker Mobile Application system user must be first log in to the system with user name and password to get the services. If the user enters invalid user name and password the system displays invalid user name and password.


Page 77


2017 GC.

4.2.6 Error Handling The system check user inputs to the system to handle error. It handles and show error by showing the message. For example if Deposit of customer who want to get the service is less than the summation of broker commission and price of the service system displays “ Your Current Deposit Is Less than Service Price“.


Page 78


2017 GC.

4.2.7 Testing by scope It tests the module of systems functionality individually and separately. Thus we used scope by scope testing i.e each subclass is tested within its own class.

4.2.8 Unit testing Unit testing the unit is tested in separation. The main aim of unit testing is to take the smallest part of a set of testable software in the application, isolate it from the remainder of the code, and resolve whether it behaves accurately as it is anticipated. Each unit test is tested separately before integrating them into modules to test the interfaces between modules.

4.2.9 Integration and system testing Integration testing: the unit parts are integrated together and then tested by the members.Is also called component testing, in a sensible circumstances, many units are combined into components, which are consecutively are consolidated into large parts of the program. The inspiration is to test combination & units take a bottom top approach from units to modules with those of other groups. Integration testing identifies problems that occur when units are combined. System testing: after all the testing’s performed, the system will be tested by professionals.Is a testing process in which the aim is to ensure that the overall system works as defined by the requirements? This stage is intended to find defects that can be exposed only by testing the entire system .The system test is done using the system test data that was developed earlier. As with previous tests that were performed, the system test may result in required modifications to programs, thus, once again, prompting the return to a design phase task. This iteration would continue until successful system test is experienced.


Page 79


2017 GC.

4.3 Sample code and sample output screen This phase, the coding is a phase where all the work during analysis and design will be turn off to a functional system prototype for the project proposed; it is divided into three parts User interface Implementation: it is designed and documented in the previous chapter (chapter four) in which users are interface with the system. Logical Implementation: - is the part in which the implementation of the functionality of the system . Database implementation: - the database implementation is now the team members are going to develop in this phase but it is also designed in the previous chapter.

“Mobile based Brokering System for Addis Ababa city sample codes” Sample Interface for GuardServant Search


Page 80


2017 GC.

Java code for Guard Servant (GuardServantSearch.java) package com.example.digitalbroker; import android.support.v7.app.ActionBarActivity; import android.text.InputType; import android.app.AlertDialog; import android.content.DialogInterface; import android.content.Intent; import android.graphics.Color; import android.os.Bundle; import android.view.Menu; import android.view.MenuItem; import android.view.View; import android.view.View.OnClickListener; import android.widget.AdapterView; import android.widget.ArrayAdapter; import android.widget.Button; import android.widget.EditText; import android.widget.LinearLayout; import android.widget.Spinner; import android.widget.Toast; import android.widget.AdapterView.OnItemSelectedListener;


Page 81


2017 GC.

public class GuardServantsearch extends ActionBarActivity { String Educ[],GoodAt[]; String educ,guardservant,goodat; Button age; @Override protected void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); setContentView(R.layout.activity_guard_servantsearch); Educ= getResources().getStringArray(R.array.EducLevel_array); GoodAt= getResources().getStringArray(R.array.GoodAt_array); age=(Button)findViewById(R.id.age); Bundle bb=getIntent().getExtras(); guardservant=bb.getString("guardservant");

final Spinner s4 = (Spinner) findViewById(R.id.spinner1);

ArrayAdapter adapter4 = new ArrayAdapter(this, android.R.layout.simple_spinner_item, Educ);

s4.setAdapter(adapter4); s4.setOnItemSelectedListener(new OnItemSelectedListener(){


Page 82


2017 GC.

public void onItemSelected(AdapterView arg0,View arg1, int arg2, long arg3){ int index = arg0.getSelectedItemPosition(); educ = s4.getSelectedItem().toString(); if(index>0){ Intent i=new Intent(getBaseContext(),Searchbyeduc.class); //i.putExtra("broker", brokeruser); //i.putExtra("check", message); i.putExtra("guardservant",guardservant );

i.putExtra("educ", educ); startActivity(i); }} @Override public void onNothingSelected(AdapterView arg0) { }}); age.setOnClickListener(new OnClickListener() { @Override public void onClick(View v) { // TODO Auto-generated method stub AlertDialog.Builder builder1 = new AlertDialog.Builder(GuardServantsearch.this); LinearLayout l=new LinearLayout(getApplicationContext()); l.setOrientation(LinearLayout.HORIZONTAL); final EditText input = new EditText(GuardServantsearch.this);


Page 83


2017 GC.

builder1.setIcon(R.drawable.not); builder1.setTitle("Input the Age Interval!"); input.setBackgroundColor(Color.GRAY); input.setInputType(InputType.TYPE_CLASS_NUMBER); input.setHint("From........................"); final EditText input1 = new EditText(GuardServantsearch.this); input1.setInputType(InputType.TYPE_CLASS_NUMBER); input1.setHint("To......................."); input1.setBackgroundColor(Color.CYAN); l.addView(input); //l.layout(10, 0, 0, 0); l.addView(input1);builder1.setView(l);

builder1.setPositiveButton("Ok", new DialogInterface.OnClickListener() {

@Override public void onClick(DialogInterface arg0, int arg1) { if(input.getText().toString().trim().length()==0){ input.setError("Enter The Inputs"); input.requestFocus();}


Page 84


2017 GC.

if(input1.getText().toString().trim().length()==0){ input1.setError("Enter The Inputs"); input1.requestFocus(); } Intent i=new Intent(GuardServantsearch.this,Searchbyage.class); i.putExtra("guardservant",guardservant ); String n1=input.getText().toString(); String n2=input1.getText().toString(); int n11=Integer.valueOf(n1); int n12=Integer.valueOf(n2);

if(input.getText().length()== 0 && {input1.getText().length()==0) Toast.makeText(getApplicationContext(), "Enter both age", Toast.LENGTH_LONG).show();

} else if(input.getText().length()== 0 || input1.getText().length()==0) { if(input.getText().length()== 0 ){ Toast.makeText(getApplicationContext(), "The minimum Age can't be empty!~", Toast.LENGTH_LONG).show();


Page 85


2017 GC.

} else if(input1.getText().length()== 0 ){ Toast.makeText(getApplicationContext(), "The maximum Age can't be empty!", Toast.LENGTH_LONG).show();}}

else if(n11>=n12){ Toast.makeText(getApplicationContext(), "The minimum Age can't be Greater Than Maximun Age!~", Toast.LENGTH_LONG).show();

} else if(n1150){ Toast.makeText(getApplicationContext(), "The Maximum Age can't be greater than 50 !", Toast.LENGTH_LONG).show();

} else{ i.putExtra("min", input.getText().toString()); i.putExtra("max", input1.getText().toString());


Page 86


2017 GC.

startActivity(i);}})

builder1.setNegativeButton("Cancel", new DialogInterface.OnClickListener() {

@Override public void onClick(DialogInterface dialog, int which) {}}); AlertDialog alertDialog = builder1.create(); alertDialog.show();}});

final Spinner s5 = (Spinner) findViewById(R.id.Goodatspinner);

ArrayAdapter adapter5 = new ArrayAdapter(this, android.R.layout.simple_spinner_item, GoodAt);

s5.setAdapter(adapter5); s5.setOnItemSelectedListener(new OnItemSelectedListener() { public void onItemSelected(AdapterView arg0,View arg1, int arg2, long arg3) {


Page 87


2017 GC.

int index = arg0.getSelectedItemPosition(); goodat = s5.getSelectedItem().toString(); if(index>0){

Intent i=new Intent(getBaseContext(),GoodAt.class); //i.putExtra("broker", brokeruser); //i.putExtra("check", message); i.putExtra("guardservant",guardservant );

i.putExtra("goodat", goodat); startActivity(i); }} @Override public void onNothingSelected(AdapterView arg0) { } });

if(guardservant.equalsIgnoreCase("guard")){ s5.setVisibility(View.INVISIBLE); }else{ s5.setVisibility(View.VISIBLE);}}

@Override


Page 88


2017 GC.

public boolean onCreateOptionsMenu(Menu menu) { // Inflate the menu; this adds items to the action bar if it is present. getMenuInflater().inflate(R.menu.guard_servantsearch, menu); return true; }

@Override public boolean onOptionsItemSelected(MenuItem item) { // Handle action bar item clicks here. The action bar will // automatically handle clicks on the Home/Up button, so long // as you specify a parent activity in AndroidManifest.xml. int id = item.getItemId(); if (id == R.id.action_settings) { return true; } return super.onOptionsItemSelected(item); } }


Page 89


2017 GC.

Xml Code for Guard Servant search(acivity_guard_servant_search.xml)

Customer Registration Form Sample Interface for Customer Registration


Page 93


2017 GC.

Java code to register customer(CreateAccount2.java) package com.example.digitalbroker;

import java.io.BufferedReader; import java.io.BufferedWriter; import java.io.IOException; import java.io.InputStream; import java.io.InputStreamReader; import java.io.OutputStream; import java.io.OutputStreamWriter; import java.net.HttpURLConnection; import java.net.MalformedURLException; import java.net.URL; import java.util.Calendar; import java.util.GregorianCalendar;

import android.app.ActionBar; import android.app.Activity; import android.app.AlertDialog; import android.app.DatePickerDialog;


Page 94


2017 GC.

import android.app.Dialog; import android.app.ProgressDialog; import android.content.Context; import android.content.Intent; import android.graphics.Color; import android.graphics.drawable.ColorDrawable; import android.net.Uri; import android.os.AsyncTask; import android.os.Bundle; import android.support.v7.app.ActionBarActivity; import android.text.Html; import android.view.MenuItem; import android.view.View; import android.widget.AdapterView; import android.widget.AdapterView.OnItemSelectedListener; import android.widget.ArrayAdapter; import android.widget.DatePicker; import android.widget.EditText; import android.widget.Spinner; import android.widget.Toast;


Page 95


2017 GC.

public class CreateAccount2 extends ActionBarActivity { String region[]; EditText bfname,blname,bdate,bphone,baddress,bemail,buname,bpw,agge; static final int DIALOG1=0; String bregiontxt; int year,month,day; @Override protected void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); setContentView(R.layout.activity_create_account2); final android.support.v7.app.ActionBar actionBar = getSupportActionBar(); actionBar.setDisplayHomeAsUpEnabled(true); actionBar.setHomeButtonEnabled(true); actionBar.setNavigationMode(ActionBar.NAVIGATION_MODE_STANDARD); actionBar.setBackgroundDrawable(new ColorDrawable(Color.parseColor("#1034A6"))); actionBar.setTitle(Html.fromHtml("Register Here!"));

bfname=(EditText)findViewById(R.id.BrokerFName); blname=(EditText)findViewById(R.id.BrokerLName); bdate=(EditText)findViewById(R.id.Brokerdateofbirth); bphone=(EditText)findViewById(R.id.BrokerPhone);


Page 96


2017 GC.

bemail=(EditText)findViewById(R.id.BrokerEmail); baddress=(EditText)findViewById(R.id.BrokerAddress); buname =(EditText)findViewById(R.id.UserName); bpw=(EditText)findViewById(R.id.Password); agge=(EditText)findViewById(R.id.age);

final Calendar cal=Calendar.getInstance(); year=cal.get(Calendar.YEAR); month=cal.get(Calendar.MONTH); day=cal.get(Calendar.DAY_OF_MONTH); // newbdate=(EditText)findViewById(R.id.newDate); showDateDialog();

region= getResources().getStringArray(R.array.Select_Region);

final Spinner s3 = (Spinner) findViewById(R.id.BrokerRegionspiner);

ArrayAdapter adapter2 = new ArrayAdapter(this, android.R.layout.simple_spinner_item, region);

s3.setAdapter(adapter2);


Page 97


2017 GC.

s3.setOnItemSelectedListener(new OnItemSelectedListener() { public void onItemSelected(AdapterView arg0,View arg1, int arg2, long arg3) { int index = arg0.getSelectedItemPosition(); Toast.makeText(getBaseContext(), "You have selected item : "+ region[index], Toast.LENGTH_SHORT).show(); bregiontxt = s3.getSelectedItem().toString(); }

@Override public void onNothingSelected(AdapterView arg0) { }}});

public void

showDateDialog(){

//date1=(Button)findViewById(R.id.buttonDateDialog); // date1.setBackgroundResource(R.id.datePicker1); bdate.setOnClickListener(new View.OnClickListener() {

@Override


Page 98


2017 GC.

public void onClick(View v) { showDialog(DIALOG1);}});}

protected Dialog onCreateDialog(int id){ if(id==DIALOG1) return new DatePickerDialog(this, dpickerListener, year, month,day); return null;

} private DatePickerDialog.OnDateSetListener dpickerListener= new DatePickerDialog.OnDateSetListener() {

@Override public void onDateSet(DatePicker view, int year1, int monthOfYear,int dayOfMonth) { day=dayOfMonth; month=monthOfYear + 1; year=year1;

String ndd=day+"/"+month+"/"+year; bdate.setText(ndd); agge.setText(String.valueOf(CreateAccount2.this.getAge(year, month, day)));


Page 99


2017 GC.

} }; public int getAge (int _year, int _month, int _day) {

GregorianCalendar cal = new GregorianCalendar(); int y, m, d, a;

y = cal.get(Calendar.YEAR); m = cal.get(Calendar.MONTH); d = cal.get(Calendar.DAY_OF_MONTH); cal.set(_year, _month, _day); a = y - cal.get(Calendar.YEAR); if ((m < cal.get(Calendar.MONTH)) || ((m == cal.get(Calendar.MONTH)) && (d < cal .get(Calendar.DAY_OF_MONTH)))) { a=a; } if(a < 0) Toast.makeText(getBaseContext(), "Age cannot Be Negative",Toast.LENGTH_LONG).show(); return a; } public void reg(View v) { String n=bfname.getText().toString();


Page 100


2017 GC.

String p=bphone.getText().toString();

String l=blname.getText().toString(); String e=bemail.getText().toString(); String re=bregiontxt.toString(); String add=baddress.getText().toString(); String un=buname.getText().toString(); String bd=bdate.getText().toString(); String pw=bpw.getText().toString(); String ag=agge.getText().toString(); String type="register"; Regbackground backwork=new Regbackground(this); backwork.execute(type,n,l,p,e,re,add,bd,ag,un,pw); } class Regbackground extends AsyncTask { Context context; AlertDialog al; ProgressDialog pdLoading; public Regbackground(Context ctx) { context=ctx; }


Page 101


2017 GC.

protected String doInBackground(String... params) { String type=params[0]; //String regurl="http://10.141.95.37/broker/regcustomer.php"; String regurl="http://192.168.43.87/broker/regcustomer.php";

if(type.equals("register")){ try{ URL url=new URL(regurl); HttpURLConnection con=(HttpURLConnection)url.openConnection(); con.setRequestMethod("POST"); con.setDoOutput(true); con.setDoInput(true); OutputStream o=con.getOutputStream(); BufferedWriter w=new BufferedWriter(new OutputStreamWriter(o,"UTF-8")); Uri.Builder builder = new Uri.Builder().appendQueryParameter("brokerfname", params[1]) .appendQueryParameter("brokerlname", params[2]) .appendQueryParameter("brokerphone", params[3]) .appendQueryParameter("brokeremail", params[4]).appendQueryParameter("brokerregion", params[5]) .appendQueryParameter("brokeraddress", params[6]).appendQueryParameter("Birthdate", params[7]).appendQueryParameter("age", params[8])


Page 102


2017 GC.

.appendQueryParameter("brokeruname", params[9])

.appendQueryParameter("brokerpw", params[10]); String query2 = builder.build().getEncodedQuery(); w.write(query2); w.flush(); w.close(); o.close(); InputStream i=con.getInputStream(); BufferedReader r=new BufferedReader(new InputStreamReader(i,"UTF-8")); String res=""; String line; while((line=r.readLine())!=null){ res +=line;

} r.close(); i.close(); con.disconnect(); return res; }


Page 103


2017 GC.

catch(MalformedURLException e){ e.printStackTrace(); } catch(IOException e){ e.printStackTrace(); } } return null; } protected void onPreExecute(){ al= new AlertDialog.Builder(context).create() ; al.setTitle("Registration status!"); pdLoading=new ProgressDialog(context ); pdLoading.setMessage("\tRegistering..."); pdLoading.setCancelable(true); pdLoading.show(); } protected void onPostExecute(String result) { al.setMessage(result); al.show(); Toast.makeText(getBaseContext(),"Successfully registered!",Toast.LENGTH_LONG).show();


Page 104


2017 GC.

Intent i=new Intent(getApplicationContext(),MainActivity.class); startActivity(i); finish(); } protected void onProgressUpdate(Void... values) { super.onProgressUpdate(values);

Customer Registration XML code(activity_create_account2.xml)


Page 111


2017 GC.

4.4. Installation Installation process of this project makes the current manual system to be replaced by the new system. This includes conversion of existing data, software, documentation, and working procedure with the new system. To the broker side:Client side 1.Broker should have to have an android platform to install this new application. 2.Then he installs the application on his platform. To the customer side:Client side 1.Customer should have to have an android platform to install this new application. 2.Then he installs the application on his platform. To the Administrator side:the server side 1.The administrator should have to have the working and installation of web browser on his computer(platform) to install this new system. 2.Then he installs this new website.


Page 112


2017 GC.

4.5 Conclusion An effort has been made to study for partial fulfillment of BSc degree in Computer Science.In doing the study we had try to follow object oriented system analysis and design methodology. Since the success and failure of any system depends on gathering the right information through different factfinding techniques and user involvements, the team has made the best effort to gather requirements. After a detail review and study of the existing system of models have been designed to reflect the new system that is supposed to solve problems. We believe that different tools and techniques has helped us a lot in capturing real user requirements and model the right system for the users for their day to day transactions.

4.6 Recommendation As we develop Digital Broker Mobile Application for Addis Ababa city we solve the problems that we listed in the first phase of the project. So we recommended to the Addis Ababa city to use this system so as to facilitate Brokering system. The things like the following will be considered  Serious consideration should be given for the introduction of the new system.  All user should have a skill of android application.  The organization should have adequate facilities for the introduction of the new system.  Behavioral change of the users of the system to adapt the new system.


Page 113


2017 GC.

5.References 

Scott w, Amber, the object primer, second edition, Cambridge University press (c), 2001.



Scott w, Amber, the object primer, third edition, Cambridge University press (c), 2004.



Bemdbruegge and Allen H. Dutit,.object oriented software engineering, third edition,2009.



Genereux and McLeod, (1995) as cited in Weimer, 2002.



Gary Shelly, Harry J. Rosenblatt, “Systems Analysis and Design”, Cengage Learning, 2009.



Preeti Gupta ,“System Analysis and Design”, Firewall Media, 2008.



Charles S. Wasson ,“System Analysis, Design, and Development: Concepts, Principles, and Practices”, John Wiley & Sons, 2006.



Charles S Wasson, “System Analysis, Design, and Development: Concepts, Principles, and Practices”, Wiley-Interscience.



Elias M. Awad ,“Systems Analysis and Design”, Richard D. Irwin, 1985 2nd edition.



https//:www.stackoverflow.com.



https//:www.youtube.com.



https//:www.codegroup.com.



https//:www.programmerguru.com.


Page 114