6.

Object Oriented Implementation

6.1 Introduction

As the design phase is completed, the systems analyst begins to focus on the tasks associated

with building the system, ensuring that it performs as designed and developing documentation

for the system. Programmers will carry out the time-consuming and costly task of writing

programs, while the systems analyst prepares plans for a variety of tests that will verify that the

system performs as expected. The final phase in the SDLC (System Development Life Cycle) is

the implementation phase, during which the system is actually built (or purchased, in the case of

a packaged software design). The implementation phase consists of developing and testing the

system’s software, documentation, and new operating procedures.

We tried to discuss issues that are highly essential for the successful implementation, such as,

installation of the new system, selection of the most suitable conversion approach, preparing the

organization and the users to adapt to the new system, and ensuring that the system is supported

after it is put into production. Our activities have been organized around six generic

implementation life cycle phases.

1. Business requirement and proposed solution: - this is the phase where core business

requirements are analyzed and developed the detail of the business process. And also, we

try to offer a software package that meets or exceeds the requirements.

2. High level design (functional specification):-the planned solution is further clarified by

functionally specifying how the system will operate and the project team converts the

business requirements for the system into system requirements that describe the technical

details for building the system

3. Detailed Design (Design Specifications): -The purpose of this phase is to figure out

what the business needs and to decide how to build it.

4. System Configuration, Optimization and development: -the system is programmed or

developed by setting up its parameters and tables with the values defined in the phases

above.

5. System Implementation: -In this phase, the system is implemented and it becomes

operational.

6. System support and maintenance: - This phase deals with post-Implementation period

in which we try to address trainings, support and maintenance in times of failures.

6.2 Implementation Technology

Frontend Technologies

Frontend technologies are those which are used to develop the web content of the system that

either the seller or the buyers interact with. It is an interface between the user and backend of

the system. In developing the system, we have used HTML, CSS, JavaScript, Ajax and

bootstrap for developing its frontend.

 HTML (Hyper Text Markup Language): is the main markup language we used for

creating static web pages and other information that can be displayed in a web browser.

 CSS (Cascading Style Sheets): used for describing the presentation semantics (the look

and formatting) of the system’s code written in a markup language.

 JavaScript: It is a programming language, commonly used with web browsers.

 Bootstrap: Bootstrap is the most popular CSS Framework for developing responsive and

mobile-first websites.
  Ajax (Asynchronous JavaScript and XML): used to send and receive data to and from

a system’s database / server.

Backend Technologies

Backend technologies is part of the code where we design it to specify how the frontend

works. for this we used Laravel(php), MySQL.

 PHP: Hypertext Preprocessor (PHP) used for dynamically generated web pages as per

client request.

 MySQL: used for accessing querying, updating, and managing data in databases.

 Server: XAMPP server in order to host the website on the local machine.

Tools that are used to develop:

 Notepad++

 Visual studio code

 GitHub

We have used environments like Apache and web browsers for deploying this project.

 Apache: is a free web server and it is easy to customize environments, fast, reliable, and

highly secure.

 Web browsers: in order to test and display the logics we have programmed.

6.3. Testing and testing procedure

Testing is an investigation conducted to provide stakeholders with information about the

quality of the product or service under test or it is the process of validity and verifying

software/program/application/product. It meets the business and technical requirements

that guided its design and development, works as expected and can be implemented with

the same characteristics.

Tests must be carefully planned because the cost of fixing one major bug after the system

is installed can easily exceed the annual salary of a programmer. A test plan contains

several tests that examine different aspects of the system. A test, in turn, specifies several

test cases that will be examined by the testers.

A program is not considered finished until it has passed its testing. For this reason,

programming and testing are tightly coupled. Testing is frequently the primary focus of

the systems analysts as the system is being constructed. The analysts must resist the

temptation to rush into testing as soon as the very first program module is complete,

however. Spontaneously testing different events and possibilities without spending time

to develop a comprehensive test plan is dangerous, because important tests may be

overlooked. If an error does occur, it may be difficult to reproduce the exact sequence of

events that cause it. Instead, testing must be performed and documented systematically so

that the project team always knows what has and has not been tested.

Test Planning

Testing starts with the tester’s developing a test plan that defines a series of tests that

will be conducted. Figure 6.1 shows a typical test plan form. A test plan often has 20 to

30 pages, with a separate page for each individual test in the plan. Each individual test

has a specific objective, describes a set of very specific test cases to examine, and defines

the expected results and the actual results observed. The test objective is taken directly

from the program specification or from the program source code. It is impossible to test
every possible combination of input and situation; there are simply too many possible

combinations. A really good test would include a test case with nonsensical, but

potentially valid, data.

There are four general stages of tests: unit tests, integration tests, system tests, and

acceptance tests. Although each application system is different, most errors are found
during integration and system testing (Figure 6
Figure 1:
Figure 6.1 Test Plan

Figure 6.2 Error Discovery Rates for Different Stages of Tests

Unit Tests

Unit tests focus on one unit—a program or a program module that performs a specific function

that can be tested. The purpose of a unit test is to ensure that the module or program performs its

function as defined in the program specification. Unit testing is performed after the programmer

has developed and tested the code and believes it to be error free. These tests are based strictly

on the program specification and may discover errors resulting from the programmer’s

misinterpretation of the specifications. Unit tests are often conducted by the systems analyst or,

sometimes, by the programmer who developed the unit. There are two approaches to unit testing:
black-box and white-box (Figure 12-5). Black-box testing is the most commonly used. In this

case, the test plan is developed directly from the program specification: Each item in the program

specification becomes a test, and several test cases are developed for it. White-box testing is

reserved for special circumstances in which the tester wants to review the actual program code,

usually when complexity is high.

Table 6-1. Register Test Case Specification

Table 6-2. Login Test Case Specification

3.reservation
Test Case ID Reservation
Test Location Reservation page
 Features to be Used Validity and completeness the Input data
Input Data User and property data
Test Cases Description the system checks that reservation info is

completely entered and they are all valid. The

system checks if the property is whether

reserved or not in the

database, in order allow or deny

Reservation.
Expectation output Pass
Result Pass

Table 6-3. Reservation Test Case Specification

4.appointment Test
Test Case ID Appointment Test
Test Location Appointment page
Features to be Used Validity and completeness the Input data

Input Data Customer and Field sales data

Test Cases Description The system checks that appointment

info is completely entered and they are all

valid. The

system checks if there is an available place in

 the field

sales schedule list and assign an appointment to

the customer 
Expectation output Pass
Result Pass

Table 6-4. appointment Test Case Specification

6.4.2 Integration Testing

Integration tests assess whether a set of modules or programs that must work together do so

without error. They ensure that the interfaces and linkages between different parts of the system

work properly. At this point, the modules have passed their individual unit tests, so the focus

now is on the flow of control among modules and on the data exchanged among them.

Integration testing follows the same general procedures as unit testing: the tester develops a test

plan that has a series of tests. Integration testing is often done by a set of programmers and/or

systems analysts. There are four approaches to integration testing: user interface testing, use

scenario testing, data flow testing, and system interface testing. Most projects use all four

approaches.
Figure 6-5. Integration testing for login module and forget password module

Table 6-6. Integration testing for registration module and login module

Test Case ID Property Addition and Gallery

Test Case Objective Test the Link between Property Add and Gallery

Page
Test Case Location Property Add and Gallery Page
 Test Case Description The authorized employee will add, edit or delete

a property (With the validation from the

Manager) once the employee is

Expected Outcome Pass/Success

Result Pass/Success

Figure 6-7. Integration testing for Property Add module and Gallery module

6.3.3. System Testing

System tests are usually conducted by the systems analysts to ensure that all modules and

programs work together without error. System testing is similar to integration testing but is much

broader in scope. Whereas integration testing focuses on whether the modules work together

without error, system tests examine how well the system meets business requirements and its

usability, security, and performance under heavy load It also tests the system’s documentation.

Stage Types of Tests Test Plan When to Use Notes

Source
System Testing Requirements System design, For normal This test ensures that

testing: unit tests, and system testing changes made as a result of

integration tests integration testing did not

tests whether
create new errors. Testers
original business
often pretend to be
requirements are
uninformed users and
met.
perform improper actions to
 ensure that the system is

immune to invalid actions

(e.g., adding blank records).

Usability testing: Interface design When user This test is often done by

tests how and use interface is analysts with experience in

convenient the scenarios important how users think and in good

system is to use interface design. This test

sometimes uses the formal

usability testing procedures.

Security testing: Infrastructure When the system Security testing is a complex

tests disaster design is important task, usually done by an

recovery and infrastructure analyst

unauthorized assigned to the project. In

access. extreme cases, a professional

firm may be hired.

Performance System proposal When the system High volumes of transactions

testing: examines and is important are generated and given to

the ability to infrastructure the system. This test is often

perform under design done by the use of

high loads. specialpurpose testing

software.
Documentation Help system, For normal Analysts spot-check or check

testing: tests the procedures, system testing every item on every page in

accuracy of the tutorials all documentation to ensure

 documentation that the documentation items

and examples work properly.

6.4. Deployment/Installation process

Software applications are not standalone systems. They are increasingly the result of the

integration of heterogeneous collections of components, possibly distributed over a computer

network. Informally, the term software deployment refers to all the activities that make a

software system available to its users. Different hardware and software will be used to install and

deploy our system. In this section we will list out the software and hard ware requirements to

deploy the system. As described in the deployment model of our design the system will be

deployed based on the concept of three-tier architecture. We do have three nodes each having

specific functionality. These are the client computer, web server computer and database server

computer. Below is hardware and software requirements for our system.

Hardware requirements

The project team identifies the following specifications:

 A personal computer with:

 3 GB RAM

 70 GB or more

Software requirements

Software Plays a Critical role as it creates convenient environment for Customers.

• The system will work over the Web Requirements imposed by business requirements environment

with Internet Explorer.

• All office locations will have an always-on network connection to enable real-time database updates.

 XAMPP/WAMP server

 PHP

 MYSQL database server

 Web-browsers
 7. CONCLUSION AND RECOMMENDATION
7.1 Conclusion
In this chapter, the team members have addressed the major Object-Oriented Design artifacts in
order to bridge the gap between analysis and implementation, which are class type architecture,
class modeling, collaboration modeling, component modeling, deployment modeling, user
interface design, and other design artifacts. These designs provide a clear understanding of
the relationship between a different component, data flow, and task or activity these components.
In second chapter, we discuss major implementation issues such as: technologies used (hardware,
software, and designing tools), compatibility issues, testing, testing procedures and deployment
processes. The project team tried to define how the system should be built, if the system is going
to be operational and used by the user. Consideration is given to ensure that the system meets
quality standards by detecting and fixing errors as soon as possible.

7.2 Recommendation
As an extension of this system, we recommend the following to be considered.
The current situation related to transfer money using E-mobile is only allowed little
amount money (10000 birrs). With kind of money is not relevant to build payment system in
this project. In the future, if the problem is solved, the system must
be modified to adopt the solution. 
Our system is very friendly, it does not require significant training. But still, the system
user(Gift real estate employee) needs some training to be familiar with the system.
To be successful in implementing the system, an organization and its management must clearly
understand the implementation process. To continue in the marketplace as a competitive
organization needs to integrate the system with suppliers and partners.

References

Dennis, Wixom,Tegarden. (2012). System Analysis & Design. An Object -Oriented Approach with UML
5th
Edition. Wiley.
Ian, S. (2009). Software Engineering. In Software Engineering (p. 790). london: pearson
publishing.
Department of Electrical and Computer Engineering University of Waterloo, Waterloo. (2008).
Software Testing and Quality Assurance. In Software Testing and Quality Assurance (p. 648).
Hoboken, New Jersey: John
Wiley & Sons, Inc., publication.
Scott, A. (2001). Object Premier 3rd edition.