Index

Tables list
Figures list
 Introduction
Machine replication of human functions, like reading, is a dream as ancient as the
invention of machines themselves. It is however, growing more than ever closer to reality.
The tremendous progress over the last five decades in machine reading is opening up endless
possibilities.
Optical character recognition (OCR) has become one of the most successful
applications of technology in the field of pattern recognition and artificial intelligence. Many
commercial systems performing OCR exist for a variety of applications, although the
machines are still not able to compete with human reading capabilities.
The advancements in pattern recognition has accelerated due to the many emerging
applications which are not only challenging, but also computationally more demanding, such
evident in OCR, Document Classification, Computer Vision, Data Mining, Shape
Recognition, and Biometric Authentication, for instance. The area of OCR is becoming an
integral part of document scanners, and is used in many applications such as postal
processing, script recognition, banking, security (i.e. passport authentication) and language
identification. The research in this area has been ongoing for over half a century and the
outcomes have been astounding with successful recognition rates for printed characters
exceeding 99%, with significant improvements in performance for handwritten cursive
character recognition where recognition rates have exceeded the 90% mark.

These advancements make it possible today to, at least partially, replace human
interactions in some processes that require speed and precision. It is not a novelty anymore to
find machine processed operations like in airports .... (formuler)

Another parallel advancement, in mobile technologies is opening a flurry of other

possibilities. Mobile phones are now such an ubiquitous asset that it is tempting to leverage
the multitude of capabilities it carries and processing power it now possesses. It is a natural
evolution for smartphones today to become the front-end of optical recognition for hundreds
of business or even everyday applications.

Our host company IRSEL, a Tunisian ICT start-up, aims to be a leader in the mobile-
processed enrolment field by being the first to market an end-to-end system to enrol
customers through mobiles. The idea originates from ground observation of the work of
customer's agents in different businesses that rely on nomad agent opening accounts for
customers. The process is most of the time paper-bound, causing multiple entries, time
consuming and error prone.

The project consists in creating an end-to-end system composed of the following:

- a mobile application (phase one is based on iOS) destined to enrolment agents. It will
be used to capture and process OCR data through algorithms then submit in a secure and
encrypted packages client data to be validated by the back-office functions
- a backend web application for administering enrolment agents, setting up the different
configurations needed and validating enrolment data.
 All the features mentioned below, are and will be integrated within the ongoing
project’s development stage.
This paper is composed, besides the previous introduction, of 4 major chapter whose
exceeding guidelines are defined below.
The first chapter present and define the general aspect of the project and deliver a
preview on the host organization, in this case it’s the company IRSEL, the purpose of the
project and the design methodology that will be followed all along this paper.
The second chapter will be dedicated for the specification and analysis of functional
and non-functional requirement of the application.
Third chapter will be devoted to an in depth description from a design concept
perspective.
Last but certainly not least, the fourth chapter will enumerate all the different
technologies implemented thereby a dedicated argument section to justify the choice and
execution and further details on implementation and the test phase of different corposants of
the application.
Chapter 1: General aspects
Introduction
In this chapter, we are aiming to put the project in its general perspective.
We propose to present, in forefront, the host organization and its different services.
We are going to provide on the next step a preview on the debatable problematic that pushed
us to come up with our main ideas for the project. Next we will elaborate on the problematic
which leads us to the main idea of the project and the given tasks to achieve. Last but
certainly not least, we will present with further details the adopted methodology for the //

Host organization
The IRSEL company
IRSEL is an Information Technology company that offers consulting services, and end-to-
end Software Solutions development for specific fields and expertise. Since its founding in
2008, IRSEL has grown steadily by every measure. Combining knowledge, quality, and
Innovation. IRSEL is the Loyal Partner of choice for companies in the United States of
America, United Kingdom, Switzerland, France, and the Netherlands for software and
Information Technology Systems, Technology Management Consulting, Product
Development, and R&D. IRSEL is based in Tunis, Tunisia.
Basic concepts//
This section offers an introduction to the basic concepts related to the problem
definition and objectives. Firstly, a brief survey of Optical Character Recognition. Later on,
multi-tenancy in the context of ///

Business Overview
Signing up uses to a new service without papers and a computer on the go is a
challenge. The idea is to use mobile phone to scan identification documents or other official
documents and to extract digital personal data (CIN, Passport, Driving licence… etc.).
Any document successfully scanned using OCR software becomes completely searchable,
editable and available for a verity of data treatment usage.

 OCR
The main principle in automatic recognition of patterns, is first to teach the machine
which classes of patterns that may occur and what they look like. In OCR the patterns are
letters, numbers and some special symbols like commas, question marks etc., while the
different classes correspond to the different characters. The teaching of the machine is
performed by showing the machine examples of characters of all the different classes. Based
on these examples the machine builds a prototype or a description of each class of characters.
Then, during recognition, the unknown characters are compared to the previously obtained
descriptions, and assigned the class that gives the best match.
In most commercial systems for character recognition, the training process has been
per- formed in advance. Some systems do however, include facilities for training in the case
of inclusion of new classes of characters.

 Component of an OCR system

A typical OCR system consists of several components. In figure 3 a common setup is
illustrated. The first step in the process is to digitize the analogue document using an optical
scanner. When the regions containing text are located, each symbol is extracted through a
segmentation process. The extracted symbols may then be pre-processed, eliminating noise, to
facilitate the extraction of features in the next step.

Figure 1 Components of an OCR system

 Segmentation
Segmentation is a process that determines the constituents of an image. It is necessary
to locate the regions of the document where data have been printed and distinguish them
from figures and graphics. For instance, when performing automatic mail-sorting, the ad-
dress must be located and separated from other print on the envelope like stamps and
company logos, prior to recognition.
Applied to text, segmentation is the isolation of characters or words. The majority of
optical character recognition algorithms segment the words into isolated characters which
are recognized individually. Usually this segmentation is performed by isolating each
connected component, that is each connected black area. This technique is easy to
implement, but problems occur if characters touch or if characters are fragmented and
consist of several parts. The main problems in segmentation may be divided into four
groups:
• Extraction of touching and fragmented characters.
Such distortions may lead to several joint characters being interpreted as one single
character, or that a piece of a character is believed to be an entire symbol. Joints will occur
if the document is a dark photocopy or if it is scanned at a low threshold. Also joints are
common if the fonts are serifed. The characters may be split if the document stems from a
light photocopy or is scanned at a high threshold.
• Distinguishing noise from text.
Dots and accents may be mistaken for noise, and vice versa.
• Mistaking graphics or geometry for text.
This leads to non text being sent to recognition.
• Mistaking text for graphics or geometry.
In this case the text will not be passed to the recognition stage. This often happens if
characters are connected to graphics.

Figure 2 Degraded symbols

 Preprocessing
The image resulting from the scanning process may contain a certain amount of noise.
De- pending on the resolution on the scanner and the success of the applied technique for
thresholding, the characters may be smeared or broken. Some of these defects, which may
later cause poor recognition rates, can be eliminated by using a pre-processor to smooth
the digitized characters.
The smoothing implies both filling and thinning. Filling eliminates small breaks, gaps
and holes in the digitized characters, while thinning reduces the width of the line. The
most common techniques for smoothing, moves a window across the binary image of the
character, applying certain rules to the contents of the window.
In addition to smoothing, pre-processing usually includes normalization. The
normalization is applied to obtain characters of uniform size, slant and rotation. To be able
to correct for rotation, the angle of rotation must be found. For rotated pages and lines of
text, variants of Hough transform are commonly used for detecting skew. However, to
find the rotation angle of a single symbol is not possible until after the symbol has been
recognized.

Figure 3 Normalization and smoothing of a symbol

 MRZ
A machine-readable zone is a machine-readable travel document (MRTD) with the
data on the identity page encoded in optical character recognition format. Many countries
began to issue machine-readable travel documents in the 1980s. Most travel passports
worldwide are MRPs. They are standardized by the ICAO Document 9303 (endorsed by
the International Organization for Standardization and the International Electrotechnical
Commission as ISO/IEC 7501-1) and have a special machine-readable zone (MRZ),
which is usually at the bottom of the identity page at the beginning of a passport. The
ICAO Document 9303 describes three types of documents. Usually passport booklets are
issued in "Type 3" format, while identity cards and passport cards typically use the "Type
1" format. The machine-readable zone of a Type 3 travel document spans two lines, and
each line is 44 characters long. The following information has to be provided in the zone:
name, passport number, nationality, date of birth, sex, passport expiration date and
personal identity number. There is room for optional, often country-dependent,
supplementary information. The machine-readable zone of a Type 1 travel document
spans three lines, and each line is 30 characters long.
Figure 4 Example of an MRZ from an MRTD
Problematic
Privacy issues has been for years a major foreshadowing threat when it comes to client
enrolment and data enragement. Privacy concerns exist wherever personally identifiable
information or other sensitive information is collected, stored, used, and finally destroyed or
deleted – in digital form or otherwise. Improper or non-existent disclosure control can be the
root cause for privacy issues. Data privacy issues can arise in response to information from a
wide range of sources. The need to provide some mechanism to protect the confidentiality of
enrolled clients have never been more serious.
When it comes to client enrolment and private data manipulation, enrolment
paperwork and old fashion scanning practices is an exceeding risk for data breach, theft of
intellectual property, identity theft, theft of equipment or information, sabotage, and
information extortion and in most cases human error cause an ongoing barrier to achieve
desired achievement in proper client enrolment measurement. Officer Enroller must often go
through manipulations and multiple entries to record a client. The most common use-case is
that the agent photocopy of the identification documents and data between hand- in paper
forms that are then transcribed by the agent himself or a third person. This mode of operation
is time consuming and causes very common mistakes.
While the old mechanisms for data registration and client enrolment is rather
superficial and a simple process to implements, to cover the whole procedure from the very
first step of collecting the physical paper documents and other biometric data to finally
submitting the enrolled clients is an enduring and resourceful procedure that is simply a
holdback during this advance technological era.

Proposed Solution
To help our customers capitalize on these changing needs, we are proposing a solution
to concrete business issue related to enrolling a large segment of clients using nomad agents
as enrollers operative. With IRSEL Enrolment System (IES) we’ve aiming to combine the
depth of intelligent recognition algorithms with capture capabilities of the mobile devices.
IES is an economical, scalable solution based on a web backend for administration/ reporting
purposes and a mobile app for agents. The system is linked through secure channels of
communication. The result is a mobile document capture software that can capture, parse,
recognize, and process personal identification document using an iOS device.
IRSEL Enrolment System (IES)
IES enable customers and remote employees to use their smartphones and tablets as a
high-performance capture and processing machines. our main goal is to simplify the
enrolment process and cut the excessive use on physical paper work.
The challenge is to be able, in real time, to recognize and extract information from images
acquired through a smartphone/tablet native camera in uncontrolled environments.
The project scope covers all types of structured documents (such as ID cards and driving
licenses) and non-structured documents (such as utility bills and bank statements).
IES recognizes hundreds of documents through bespoke templates and allows users to create
their own.
Benefits
Improve Data Accuracy and Eliminate Lost Documents. Thanks to our ‘Campaigns’
mechanism. all document must be arranged programmatically into a workflow structure that
ensure the binding of different document under the same enrolled client on the same scanned
package. This procedure guarantees the grouping and the safety of such sensitive personal
information.
Ultimate flexibility with minimal configuration. The IES platform is built in order to offer
clients enroller and business partners to fully customise their own campaign workflow
extravaganza, in order to apply different mobile capture functionality in multiple scenarios
Eliminate the opportunity for user error. Straight-through processing hinges on the quality
of the original image captured. Only IES offers Automatic smart mobile image technology,
which functions as ‘automatic capture’. As soon as the mobile device is adequately
positioned, the camera automatically snaps the photo. Eliminating the additional step of
having to manually take the photo reduces user error. Automatic capture ensure the best
quality image in the shortest amount of time.
 Adopted Methodology
AGILE METHODS
In order to build an application, it’s often very challenging to establish from the very
beginning, strict and clear parameters, due to the fact that clients tend in general to add or
remove some functionalities during the developing cycle of the project.
The preferential choice of the designing methodology needs some sort of a
comparative study between the most successful names in the business. this comparative study
is illustrated within the table below.

Principles Strengths Weaknesses

- Sequentially placement of - Easy to understand and easy to
Cascade the project phases. use.
- Provides a reference to
inexperienced staff.
- Milestones are well-
understood by the team.
- Provides requirements
stability.
- iterative and incremental -Iterative.
2TUP (Tracks - proposes a development - Strong emphasis on
Unified cycle in Y. technology and risk
Process) -Aim to all size projects management.
-Sets stakeholder profiles,
deliverables, schedules and
prototypes.
- UML based. - Iterative-incremental process
RUP(Rational - Use case driven, a feature - Establish the dialogue between
Unified inherited from OOSE. the various stakeholders of the
Process) project ( deliverables ,
- Covering the full generic schedules and prototypes)
lifecycle. - Recommend a model of
documents, and canvas for
typical projects.
- Can give a false impression
of progress.
- Integration is one big-bang at
the end.
- Little opportunity for
customer to preview the
system.
- Rather superficial on the
phases upstream and
downstream development:
capturing needs, support,
maintenance
-Ne propose pas de documents
types.
-Expensive.
- Very complex process :
- configuring the process is a
formidable task in itself
- The process is confusing to
those involved. The iterative
incremental nature of the
process further complicates
the issue.

- Set the " Best Practices "
XP (eXtreme of development (teamwork,
Programming) skills transfer ...)
- Target projects of less
than 10 people.
- Iterative.
- Simple to implement.
- Made an emphasis on the
technical aspects : prototyping,
development rules , tests, etc.
- innovative
- Does not cover the upstream
and downstream development
phases (capture needs,
support, maintenance,
integration test , etc.)

Table 1. Summary of development methodologies

Selected methodology
The project represents a certain complexity to technical and functional level as it is in
new emerging technologies which are the web, web services and iOS app development, hence
the need for a phase to study and take consideration all these requirements before further
advance the functional specifications study. We must begin to investigate the logic and focus
on the study of scenarios of use and functionality.
In the software engineering domain, there are several approaches for development. It
is important to distinguish the modeling techniques from the management methods. The
application modeling techniques are based on models like "entity-relation", "flow", "object".
New technologies, among which our project is, often use object models. The standard in term
of analysis and modeling is UML. The management or development methods on which rest
the project’s management is based on four elements:
• a model,
• a language,
• a process,
• tools.
At some point, a connection between the functional model and the technical one must
be made to ensure the adaptation of the technical architecture with the needs of the
organization.
The project aiming to implement through this training institute needs to meet the
characteristics of projects that stand in need for the adequacy of the technical requirement in
terms of functionality desired by the clients. For this reason, choosing a project management
method such as 2TUP is justified for several reasons:
• It is an incremental process, allowing a better technical and functional risk
management and thus constituting the deadlines and the costs control.
• It is an iterative process. The degrees of abstraction are increasingly precise at each
iteration.
• It is component oriented, offering flexibility to the model and supporting the re-use.
• It is user oriented because built from their expectations.

Our goal is to propose a rapid way to develop a project design for mobile phones apps and
web applications. Secondly, we wanted to move along at the same pace the functional and the
technical parts. Finally, we wished some good graphical representations (Y-shaped process,
UML diagrams) and different understanding levels (abstract idea, coding, …). The 2TUP
method answers to all these requirements.
Figure 2.The process of developing in 2TUP
Modelling
2TUP is a unified process (i.e. a software development process) built on the UML
modelling language.
The 2TUP process answers to the constraints of change of the information systems
subjected themselves to two types of constraints: functional constraints and technical
constraints as shows it the following diagram:

In concrete terms, the process is modelled by two branches (tracks):

• A functional track (capitalization of knowledge trade)
• A technical track (re-use of a technical knowhow).

Then these two tracks amalgamate for the realization of the system. This is why this
process is still called Y shaped process. With this development process, a model is essential in
order to anticipate the results. A model can be used with each step of the development with an
increasing detailed manner. The industrial standard of object modelling, UML, was selected
as the development tool. It appeared very difficult to consider the 2TUP process without using
UML and, more particularly UML 2.0 which support the oriented design component.

Project planification
The first phase of the implementation starts with the preliminary study which introduces
the project. The specifications, initial document of the functional and technical needs, are
partly the result of this work. It is supplemented by the modelling of the total system context.
Not everything is to be described at this stage but simply to identify the external entities
interacting (actors), to list the interactions (messages) and to represent this unit on a model
(context).

Feature Track
The functional branch makes an inventory of the functional needs and analyses it. This
phase formalizes and specifies the elements of the preliminary study. The applied use case
technique translates the whole interactions between the system and the actors. The obtained
use cases are then organized (treated on a hierarchical basis, generalized, specialized...). They
make it possible to identify the classes and they permit the oriented object modelling
generated in the analysis part.
 Estimated Effort
Functional Track
(Days)
Estimated
Phase track Effort

Functional requirement.

Analysis

Table 2. Functional Track

Technical track
The technical branch lists the technical needs and proposes a generic design validated
by a prototype. The pre-necessary techniques revealed in the preliminary study, showing the
operational needs and the strategic choices of development, lead to the development of the
construction process. To do this, several stages are necessary:
• The inventory of technical specifications related to the hardware,
• The inventory of the software specifications.
The list of tasks to be followed during this branch are organized in decreasing order of
priority in Table 3

Estimated Effort
Technical Track
(Days)

Phase track Estimated Effort

Functional requirement 5 20

Software design. 15

Table 3. Technical Track

Middle Track
The medium branch supports the preliminary design, the detailed design, coding, the
tests and the validation. The preliminary design is one of the most sensitive steps of the 2TUP
process. It represents the fusion of the functional and technical tracks. It finishes when the
deployment model (working stations, architectures), the operating model (components,
applications), the logical model (classes diagrams, classes), interfaces (users and components)
and the software configuration model are defined.

The list of tasks to be followed during this branch are organized in decreasing order of
priority in Table 4.
 Estimated Effort
Middle Track (Days)

Phase track Effort estimé

Conception préliminaire 5

Conception détaillée 5 70

Codage et tests 40

Recette 20

Table 4. Middle Track

Conclusion

This chapter discusses the overall context of our project. The presentation of the host
company IRSEL was followed by a brief analysis of customer needs and a relatively detailed
description of the current situation, the problems and objectives of the proposed project.
Finally, we presented the methodology and the formalism adopted for the realization of our
project. This proves important to outline our work to understand the reasons for this project
and facilitate its development. The next chapter focuses on the analysis and specification of
requirements of our solution.
Chapter 2: Specification of
requirement
Introduction
Phase analysis and specification of requirements is difficult because it is what will
determine the positive result of the project, affecting a very critically subsequent operation of
the achieved product. Indeed, in this chapter we will analyse in further detail the different
obligations dictated by the specifications and the functionalities that the solution must offers
to the client.
We will begin to express the needs of this solution, next, we will highlight the different actors
that interact with the application. Finally, we model the features that must offer the
application through diagrams of use cases.

Requirement
Functional requirement
Functional requirements are defined as all the expected requirements by different
actors of the system. These requirements are:

Backend
- The system must provide the possibility for admins to configure the
Campaigns.
- The system must provide the possibility to configure the Templates and
capturing zones.
- The system must provide the possibility for admins to check and validate
submitted enrolments.
- The system must provide the possibility to manage and configure the users of
the applications (both admins and agents).

Front mobile
- The system must provide the possibility to capture and identify id card and
official physical documents.
- The system must provide the possibility to extract the data from identified
documents applying the pre-configured OCR zones.
- The system must provide the possibility to extract data from documents with
an MRZ zone attached.
- The system must provide the possibility of end to end secure communication to
send the extract data pack to be processed and analysed to backend servers.

Web Service Communications

- The system must provide the possibility of authentication via mobile app
- The system must provide the possibility to download configurations assigned
to agents.
- The system must provide the possibility to submit an enrolled campaigns.
Identification of Actors
We have been able to identify two major actors in the system:
Admin: responsible to the configuration of the backend solution.
Agent: clients’ enroller.

Overview of the system

To model all the use cases in the system, we chose the UML modelling language. As
we mentioned earlier, the system contains two main actors: Agents and Admins. The diagram
shown in Figure 3 describes the different operations for the user during the functioning of our
system.

Figure 5 Overview of the system

Use cases of the system
After a profound study, we have been able to identify the major features that we need to
provide for the realization of our project.
In this part, the expected features of the system are presented and organized by actor.
 Agent Use cases
The system allows the agent to:

 Through the mobile application:

- Authenticate
- Scan documents from an assigned Campaign
- Submit enrolment’s packs to server
- Check assigned Campaigns
 Through the web backend application:
- Authenticate
- Review submitted enrolment history
- Check assigned Campaigns

As from version 1 of the system, the mobile application allows the agents to fully
handle the scanning process while being offline, no internet connection is needed unless the
agent needs to submit enrolment packs to server.
The use cases we have cited are detailed in the diagram in the following figure. In the
successive, a few cases of this diagram, will be detailed through textual descriptions and
system explained in the sequence diagrams.
Refinement requirements
The refinement is a necessary and highly significant transaction as it will allow to
better understand in more detail the features of the system.
In what follows, we will refine the overall digraph shown in Figure 3 by keeping stock
of each use case that includes.
 Authentication
The description of the use case ‘Authentication’ is presented in the table below:

Purpose The user needs to fully authenticate within the system

Summarize The process of establishing confidence in user identities electronically

presented to an information system. In online environments, the username identifies
the user, while the password authenticates that the user is whom he or she claims to
be. In our project, accessing the mobile/web platform require the user to submit its
username and password in order to be properly identified.

Agent - Admin
Actor
1. Establish connection.
pre condition 2. Each actor must acquire a login and a password registered in the
application’s database.

Description of 1. The actor launches the application

sequences 2. The system displays the authentication form
3. The actor inputs his connections settings
4. The system verifies the entered data
5. Login successful or unsuccessful

1. The actor can access system

Post condition 2. if the actor connects through the mobile application, A home menu will be
presented and he can access all the mobile application features.
3. if the actor connects through the web backend application; 2 possible
scenarios are granted:
4. If the actor is an “Agent” he can access the dashboard home page, the
campaigns whish he is assigned and his submitted enrolments.
5. If the actor is an “Admin” he can access the dashboard home page, and all
the backend features.

Exception(s) 1. authentication failed

2. No established connection
3. Wrong username or password
 Check assigned Campaigns
Purpose The agent can check it’s assigned campaigns

Summarize On both the backend web application or the mobile app, the agent can
authenticate and check his/her assigned Campaigns to work with.
A campaign is a workflow of steps the agent needs to fulfil in order to
enrol one client. every step is composed of one document to be captured
either by a simple take for a ‘Classic’ step or to be processed using OCR
algorithms in order to extract raw data from the document.
Actor Agent
Pre condition
- Fully authenticate or using the offline mode feature.

Description of - the agent lunches the campaigns interface

sequences
- the app lists all the campaigns that are assigned to the agent
- the agent selects one campaigns
- the app expands the view to show all the steps needed to
accomplish the enrolment

Post condition Campaigns list displayed

Exception - no campaigns are assigned to the agent
 Scan documents

Purpose The agent needs to scan a physical document

In order to enrol clients to an external third party information system, many

Summarize personal information and documents are needed according to the custom campaign
settings. The agent must first select the campaign to work with, then advance by
filling up the steps of the workflow by scanning physical document using the IES
mobile application.

Agent
Actor
- Fully authenticate or using the offline mode feature.
pre condition - All the physical document to be scanned are available

1- The agent launches the Campaigns interface

Description of 2- The app lists all the campaigns that are assigned to the agent
sequences 3- the agent selects which campaigns to pursuit
4- the app lists all the steps (documents) needed to be scanned
5- the user selects a step to scan/capture a document
6- if the document requires OCR processing, an interface will popup with the
extract data from the physical paper.
7- Once the scan has been executed, the steps list re-appear listing all the
remaining steps needed to be scanned, once all the steps have been
executed, the agent can save the enrolled pack locally on the device.
1- the saved enrolment pack is stored locally on the device waiting to be
Post condition synchronized to server.
2- the agent can either submit or delete an enrolled pack.

Exception(s) 1- One or more physical document is missing

 Submit enrolled packs to server
The agent can submit the enrolled packs to server for approve.
Purpose
Back when the agent had accomplished all the step of one campaign,
Summarize the saved data is stored locally in his device waiting for
synchronizing. Once the data is fully transmitted to the backend
servers. the data is automatically erased for security measures.

Agent
Actors
- Authentication through the backend web application
Pre condition - Internet connection
- the agent selects to synchronized all enrolled packs.
Description of - the app synchronizes all the locally stored enrolments packs to the
sequences servers.
- the app erase all the enrolments packs from the device database.

- Synchronize enrolments packs to servers

Post condition
- No previous enrolments have been made
Exception
  Admin use case
The application allows the admin to:

- Authenticate
- Manage agent’s accounts
- Approve submitted enrolments
- Create custom Templates
- Create custom Campaigns

The use cases we have cited are detailed in the diagram in the following figure. In the
successive, a few cases of this diagram, will be detailed through textual descriptions and system
explained in the sequence diagrams.
 Check submitted enrolment
The admin can either accept or decline an agent submitted enrolment.
Purpose
Once the agent had submitted an enrolment pack to servers, its
Summarize automatically receive the “pending” status, the enrolled pack will stay
on hold until the intervention of an admin, who can eventually accept
or decline the agent’s submitted enrolment.

Admin
Actors
- Authentication through the backend web application
Pre condition - Internet connection
- The submitted enrolment acquire the status ‘pending’
- The admin selects one enrolled pack from a list.
Description of - The system displays all the document within the package
sequences - The admin either accept or decline all the document from
the enrolled pack

- Status changed to ‘Valid’ if the admin accept the enrolled

Post condition pack.
- Status changed to ‘Invalid’ if the admin choose to decline
the submitted pack
- No previous enrolments have been made
Exception
Management of Use cases

a) The relations of inclusion, extension and generalisation

 Inclusion of use case: Authentication

If we look carefully through the text descriptions of the use cases of our system. We
can quickly detect that in all the pre-conditions provided, we specified that the main actor of
the use case must authenticate. In fact, the authentication process involves a flow of events
between the actor and the system entering a username and a password with different cases of
possible error. Accordingly, this case corresponds exactly to the concept of use cases
included.

 Extension of use case: Review campaigns

If we resume the textual description of the event "Configure campaigns", admin and
according to their choice, he can either create, edit or delete one custom campaign.
Export to excel: the admin can export all the created campaigns to an excel format.
Review Steps: a campaign is not complete without a set of steps to accomplish the
workflow of enrolment, admin can either create, edit or delete a custom step, Steps cam either
be composed of:
- OCR STEP: an OCR step is a step that contains one Template of a physical
document preconfigure to be processed through our mobile app OCR engine in
order to extract real text data from it.
- MRZ Step: as we mentioned in the beginning of this paper, a machine-readable
zone (MRZ) is a machine-readable travel document (MRTD) with the data on the
identity page encoded in optical character recognition format. MRZ contains a
reliable and secure information about the physical document that can be extracted
through an MRZ scan.
- Classic step: is a simple image capture of a document that don’t require an OCR
scan.
  Extension of Use Case ‘Review Templates’

If we resume the textual description of the event "Configure campaigns", admin and
according to their choice, he can either create, edit or delete one custom campaign
Export Template’s configuration to Excel format: the admin can export one
templates’ list of field to an excel format document for external use.
Review fields: Field are an essential component of a template life cycle, in order to
scan a document, the OCR engine must learn all the required field needed to perform the OCR
processing on a small portion of a physical document, this procedure is a crucial time saver as
it reduce the time of the OCR processing and further improve the OCR final results.
the admin can either add, delete or edit a field from one template.
  Extension of use case ‘Check submitted campaigns’

If we resume the textual description of the event ‘Check submitted campaigns’, admin
is the main executive supervisor to resolve the submitted enrolments through the backend
application. Admin can either delete, edit or decide by either accept or refuse a submitted
pack of enrolment judging by its content.

 Extension of use case ‘Review user’s account’

If we resume the textual description of the event ‘Review user’s accounts’, admin and
according to their choice can either:

- Add new user to the system

- Edit user specifications
- Check the agent’s last location through Google map
- Assign a campaign to an agent
- Block an agent from accessing his/her account through both platforms
- Assign different roles to users
 b) Structuring use cases into packages
Use Case Actor Package

Scan document Client enrolments

Agent
Submit enrolment to approval

Enrolment approval

Managing Templates
Admin Backend Settings

Managing Campaigns

Managing users

Authentication Actor Access management

Non Functional requirement

The main goal of the technical branch of the Y process is to identify the constraints and
the technical choices and physical sizing system design. The goal is to avoid technical risks
and problems that the application may encounter such as integration, interoperability and
evolution.
Security:
- The system must guarantee the security of data access, personal information are
very sensitive when it comes to data breach and electronic document protection,
that is why we provided our project with an encryption system to further assure the
protection of personal data.
- The application manages the roles and access rights for each user.
Ergonomics: The interface of the application must be understandable and easy to use
by any user types
Speed: The operation of the application must present an acceptable speed for users

Technical requirement
Software architecture: MVC

The Model-View-Controller (MVC) design pattern assigns objects in an application

one of three roles: model, view, or controller. The pattern defines not only the roles objects
play in the application, it defines the way objects communicate with each other. Each of the
three types of objects is separated from the others by abstract boundaries and communicates
with objects of the other types across those boundaries. The collection of objects of a certain
MVC type in an application is sometimes referred to as a layer—for example, model layer.
MVC is central to a good design for a Cocoa application (iOS) and a PHP framework
(symfony3). The benefits of adopting this pattern are numerous. Many objects in these
applications tend to be more reusable, and their interfaces tend to be better defined.
Applications having an MVC design are also more easily extensible than other applications.
Moreover, many Cocoa technologies and architectures are based on MVC and require that
your custom objects play one of the MVC roles.
Model Objects

Model objects encapsulate the data specific to an application and define the logic and
computation that manipulate and process that data. For example, a model object might
represent a character in a game or a contact in an address book. A model object can have to-
one and to-many relationships with other model objects, and so sometimes the model layer of
an application effectively is one or more object graphs. Much of the data that is part of the
persistent state of the application (whether that persistent state is stored in files or databases)
should reside in the model objects after the data is loaded into the application. Because model
objects represent knowledge and expertise related to a specific problem domain, they can be
reused in similar problem domains. Ideally, a model object should have no explicit connection
to the view objects that present its data and allow users to edit that data—it should not be
concerned with user-interface and presentation issues.

Communication: User actions in the view layer that create or modify data are communicated
through a controller object and result in the creation or updating of a model object. When a
model object changes (for example, new data is received over a network connection), it
notifies a controller object, which updates the appropriate view objects.

View Objects

A view object is an object in an application that users can see. A view object knows
how to draw itself and can respond to user actions. A major purpose of view objects is to
display data from the application’s model objects and to enable the editing of that data.
Despite this, view objects are typically decoupled from model objects in an MVC application.

Communication: View objects learn about changes in model data through the application’s
controller objects and communicate user-initiated changes—for example, text entered in a text
field—through controller objects to an application’s model objects.

Controller Objects

A controller object acts as an intermediary between one or more of an application’s

view objects and one or more of its model objects. Controller objects are thus a conduit
through which view objects learn about changes in model objects and vice versa. Controller
objects can also perform setup and coordinating tasks for an application and manage the life
cycles of other objects.

Communication: A controller object interprets user actions made in view objects and
communicates new or changed data to the model layer. When model objects change, a
controller object communicates that new model data to the view objects so that they can
display it.
Specification from a hardware perspective
The hardware configuration of our project is schematically presented in the figure below

Our project is implemented on a 3-tier architecture. The basic principle of this

architecture is relatively simple: it involves separating the achievement of three parts:
presentation (client), business logic (application server) and data storage (data server). much
like the client-server architecture, this separation means that it is possible to deploy each part
on a separate server. The implementation of this type of architecture provides greater system
scalability.
As shown in the figure, our solution is composed of three layers or levels. The first
layer is the client can be presented by either a mobile device for the mobile application and a
web browser to access the web application.
The second layer server has an internal web server, which contains the web
application.
The third layer is the database server component.
Development of a software specification model

Once the technical specifications and architecture are expressed, we can observe to the
specific features of the technical system by conducting a software specification.

a) Technical operators
The operator is an actor within the meaning of UML, except that it has the technical
capabilities of the project. Compared to our system, we can distinguish:
The Actor how can access both the mobile and the backend application, all actors in
the functional branch are in fact actors within the technical dimension.
The operating engineer who is responsible for deploying and troubleshooting the
system.
b) Technical use cases
A case of technical use is intended for the operator. It is a sequence of actions that
produce an operational added value or purely technical.
The technical case using our Intranet application are first identified by considering the
operational expectation of each operator:

 The user will work with entities as objects, which implies the implementation
mechanisms of persistence and life cycle management of objects.
 Multiple users can work in parallel. Integrity is the mechanism that prevents
the simultaneous update of a single entity by two different users.
 Each user also has a load management at the server level. Thus, the system
response time is not finding degraded depending on the number of connected
users.
 The user must log in and be known to the system to work. Authentication is the
mechanism that protects the system from external intrusions.
 The system must be operative; as such, it must be able to generate alerts and
tracks that will facilitate maintenance within the overall computer system of
the company. It is this technical problem analysis for introducing the operating
engineer as another system operator.
 The operating engineer and the user are subject to safety rules.
 In a client / server system these aspects are covered like, authentication,
authorization, Encryption, non-repudiation and auditing.
Conclusion
In this chapter we have detailed functional and technical needs of our application. The
next chapter will be devoted to the design of the application requirements.
Chapter 3: System design
3.1. Introduction
Once the two branches of the Y model are planned and thoughtfully plotted, we can
start the system object’s analysis that we need to accomplish. We illustrate our analysis with
the breaking into categories, the development of the static model and dynamic model and a
presentation of the design class diagrams.

3.2 Breaking into categories

The division into categories is the first activity of the analysis step which is refined
iteratively during the project. It is located on the left branch of the Y cycle and succeeds the
capture functional requirements. Late in the needs analysis, we get a functional breakdown
expressed through use cases held in the functional specification model.
3.2.1. Identification of categories

One category consists of logical grouping of classes in high internal consistency and
low external coupling. The division into categories is based on two fundamental principles:
consistency and independence.
Our application can be composed of three sets of classes:

Category ‘Enrolment’: for the controlling of the creation, submitting and evaluating the
enrollments packages. This category holds the classes: Enrolment, Evaluate
Category ‘User management’: for the management and the configuration of actor users
within the system, this category holds the classes: Admin, Agent, User.
Category ‘Configuration’: for the class

3.2.2. Dependency between categories

The different dependency relationships between the three categories of our application
are shown in Figure below.
3.3 Development of the static model: Class diagram

The development of the static model is the second stage of analysis. The established
class diagrams modeled breaked into categories, will be supplemented and optimized. This is
an iterative activity, coupled with highly dynamic modeling.
The final class diagram of our application is described by Figure 41
Class Description

User The class User is the parent class of the

inheritance class Agent and Admin
Admin The class Admin represents all the
administrators of the backend application that
are in charge of evaluating the submitted
enrollment and the configuration of the
different elements of the application such as
Templates, Campaigns, user managements,
etc.
Agent The class Agent represent all the agent
authenticated through the mobile application
that are responsible for scanning and
submitting the enrolled clients and theirs
personal documents
Enrolment The class Enrolment represent all the
submitted enrolment posted by the agents
Campaigns The class Campaigns represent the different
workflow campaigns created in the
application, each campaigns is composed of
different Steps
Steps The class Steps represent the group of steps
of the workflow that form one Campaigns.
Each step is composed of one Template
Template The class Template represent all the physical
documents that will be scanned through the
mobile application, each Template is
composed of many Fields
Field The class Field represent each row of a
document that will be scanned through the
OCR engine,

3.4. Development of the dynamic model: object sequence diagram

This part will allow us to illustrate the use of dynamic concepts of UML diagrams and
associated under the analysis phase by describing scenarios involving a set of objects
exchanging messages. These interactions are described by sequence diagrams that focuses on
the chronology of the messages. This section will be dedicated to present some sequence
diagrams of our application.

3.4.1 Authentication object diagram

Authentication is a case of unsustainable use in any software application whose
purpose is to limit and secure the access to the system. In our solution, the user authenticates
via mobile app or backend web application and parameters are sent to the server to be verified
through the Authentication service inside our solution.
3.4.2 Enrolment Object diagram
One of the main goal of our application is the ability to enroll client on the go using
their respective personal documents, in order to enroll multiple clients, the agent must login
through their mobile application to start the enrolment process that start with scanning the
physical document and finalize by synchronizing all the captured data to our backend servers.
3.4.3. Review submitted enrolment object diagram

An Agent enrolment process will not be completed without an admin decision on either to
verify and approve the enrolment packs or refuse and reject it, in either case scenario, the
Agent will be notified immediately by a remote push notification.

Conclusion
In this chapter we have associated the two 2Tup branches: technical and functional
one. This was established through the objects sequence diagrams and the class diagrams. We
will wrap-up this paper by an implementation phase which will be described in the next
chapter.
Chapter 4: Production and test
4.1. Introduction
We have perceived in the previous chapters the different conceptual aspects of our
application. In this chapter, we present the hardware and software environments used,
describes the various technical choices related to the project and present the chronology of the
tasks performed throughout our work. We will eventually present some screenshot of the final
product for specifying interactions with our system.

4.2. Production and work environment

This section presents the work environment, the different development phases and the
final result of the product.

4.2.1. Software environment

We present in this part of the software used for the realization of our application.

 Xcode

In order to develop the front end of our application, we have used the IDE Xcode for
developing the iOS app.
Xcode is an integrated development environment (IDE) containing a suite of software
development tools developed by Apple for developing software for macOS, iOS, WatchOS
and tvOS.
Xcode supports source code for the programming languages C, C++, Objective-C,
Objective-C++, Java, AppleScript, Python, Ruby, ResEdit (Rez), and Swift, with a variety of
programming models, including but not limited to Cocoa, Carbon, and Java.
Thanks to the Mach-O executable format, which allows fat binary files, containing
code for multiple architectures, Xcode can build universal binary files, which allow software
to run on both PowerPC and Intel-based (x86) platforms and that can include both 32-bit and
64-bit code for both architectures. Using the iOS SDK, Xcode can also be used to compile
and debug applications for iOS that run on ARM architecture processors.

 MAMP Server

As a standalone web server, MAMP has helped us to run dynamically our backend web
application.
 MAMP is a solution stack composed of free and open-source and proprietary
commercial software used together to run dynamic web sites on Apple Macintosh computers.
MAMP is an acronym of Mac OS X, the operating system; Apache, the web server; MySQL,
the database management system; and PHP, Perl, or Python, all programming languages used
for web development.

Operating system Mac OS X

Web server Apache
Database management system MySQL
Web development PHP

 PhpStorm

Our backend solution has been built entirely on the web IDE: PhpStorm
JetBrains PhpStorm is a commercial, cross-platform IDE for PHP built on JetBrains'
IntelliJ IDEA platform.
PhpStorm provides an editor for PHP, HTML and JavaScript with on-the-fly code
analysis, error prevention and automated refactoring’s for PHP and JavaScript code.
PhpStorm's code completion supports PHP 5.3, 5.4, 5.5, 5.6 & 7.0 (modern and legacy
projects), including generators, coroutines, the finally keyword, list in foreach, namespaces,
closures, traits and short array syntax. It includes a full-fledged SQL editor with editable
query results.
PhpStorm is built on IntelliJ IDEA, which is written in Java. Users can extend the IDE
by installing plugins created for the IntelliJ Platform or write their own plugins.

 draw.io

draw.io is an online service that is used to model, represent and visualize information.
Among other uses, such diagrams are often used in software and technical development and
business to represent data flows, workflows, software architecture and organizational charts.
4.2.2. Technologies and programming languages

For building and creating ‘IRSEL Enrolment System’ we have used many
technologies that will be mentioned and introduced in the list below:

 iOS SDK

The iOS SDK (Software Development Kit) (formerly iPhone SDK) is a software
development kit developed by Apple Inc. and released in February 2008 to develop native
applications for iOS.
As iOS uses a variant of the same XNU kernel that is found in OS X, the tool chain
used for developing on iOS is also based on Xcode.
The SDK contents is broken down into the following sets

- Cocoa Touch (Multi-touch events and controls, Accelerometer support,View

hierarchy, Localization, Camera support)
- Media (OpenAL, audio mixing and recording, Video playback, Image file formats,
Quartz, Core Animation, OpenGL ES)
- Core Services (Networking, Embedded SQLite database, Core Location, Threads,
CoreMotion)
- Mac OS X Kernel (TCP/IP, Sockets, Power management, File system, Security)

Along with the Xcode toolchain, the SDK contains the iPhone Simulator, a program
used to simulate the look and feel of the iPhone on the developer's desktop. Originally called
the Aspen Simulator, it was renamed with the Beta 2 release of the SDK. Note that the iPhone
Simulator is not an emulator and runs code generated for an x86 target rather than ARM.

 Swift
Swift is a general-purpose, multi-paradigm, compiled programming language created for iOS,
OS X, watchOS, tvOS, and Linux developed by Apple Inc. Swift is designed to work with
Apple's Cocoa and Cocoa Touch frameworks and the large body of extant Objective-C
(ObjC) code written for Apple products.
Swift is intended to be more resilient to erroneous code ("safer") than Objective-C,
and more concise. It is built with the LLVM compiler framework included in Xcode 6 and
later and uses the Objective-C runtime library, which allows C, Objective-C, C++ and Swift
code to run within one program

 Symfony 3.0

Symfony is a PHP web application framework for MVC applications. Symfony is free
software and released under the MIT license.
Symfony aims to speed up the creation and maintenance of web applications and to
replace repetitive coding tasks.
Symfony has a low computing overhead used with a bytecode cache.
Symfony is aimed at building robust applications in an enterprise context, and aims to
give developers full control over the configuration: from the directory structure to the foreign
libraries, almost everything can be customized. To match enterprise development guidelines,
Symfony is bundled with additional tools to help developers test, debug and document
projects
 PHP

PHP (recursive acronym for PHP: Hypertext Preprocessor) is a widely-used open

source, server side, general-purpose scripting language that is especially suited for web
development and can be embedded into HTML.
  HTML, CSS, JAVASCRIPT

HTML
HTML5 is the latest version of Hypertext Markup Language, the code that describes
web pages. It's actually three kinds of code: HTML, which provides the structure; Cascading
Style Sheets (CSS), which take care of presentation; and JavaScript, which makes things
happen. HTML5 has been designed to deliver almost everything you'd want to do online
without requiring additional software such as browser plugins. It does everything from
animation to apps, music to movies, and can also be used to build incredibly complicated
applications that run in your browser.

CSS
Cascading Style Sheets (CSS) is a style sheet language used for describing the
presentation of a document written in a markup language.

JAVASCRIPT
JavaScript ("JS" for short) is a full-fledged dynamic programming language that, when
applied to an HTML document, can provide dynamic interactivity on websites.

4.3. Hardware environment

4.3.2. Development hardware components
In order to build and develop our product, we got to use the following computer
specifications
 One computer
4.4. Project Management
4.4.1. Project management tool: Redmine

Redmine is a free and open source, web-based project management and issue tracking
tool. It allows users to manage multiple projects and associated subprojects. It features per
project wikis and forums, time tracking, and flexible role based access control. It includes a
calendar and Gantt charts to aid visual representation of projects and their deadlines. Redmine
integrates with various version control systems and includes a repository browser and diff
viewer.
4.5. Application interfaces
4.5.1. Scenario 1: Client enrolments

While developing our product, we focused highly on the graphic interfaces to get a user
experience that respects the rules of ergonomics of human-computer interfaces.

Authentication interface: mobile version

This interface is defined as the authentication page of our application. The need to
authenticate not only secure access but to build-up the logic and populate the data within the
mobile app, the first launch of the application required the Agent to login in order to
download their assigned campaigns and configurations.

In case of an invalid password or identifier, as any authentication system, our

application first checks the identifier and the user password that attempts to connect to the
application. If the password or the username is incorrect, the application warns the user with
an error message.

Offline mode: Every now and then the agents will eventually find himself in a situation/place
were he will not have access to internet connection to authenticate through the app.
 Mobile dashboard interface

The mobile mini dashboard is the first interface the user is redirected after he properly
authenticated. The interface is rather simple with minimal UI components and and essential
displaying info, the main use of this interface is to navigate the agent through different
functions that our applications offers by clicking on the menu button under the avatar profile
picture to open up our circle menu.
On the lower half of the screen, the agent is presented with a simple data charts that
display the state of his enrolment behavior from the day he started using the application.

o Valid: the percentage of the approved enrolment by an administrator

o Invalid: the percentage of the rejected enrolment by an administrator
o Pending: the percentage of enrolments that have not been reviewed by an
administrator yet

Finally, on the very bottom of the interface, the agent can access his assigned campaigns
directly through a dynamic button that display the number of campaigns assigned to him.
 Campaigns list interface

Once the Agent click on the button of assigned campaigns, the app displays all his
assigned campaigns in an elegant card form that shows many types of information about a
certain campaign.
Each card displays the campaign name, the description of the campaigns, number of
steps needed to enrol one client. and the expiry date of one campaign. And on the left of each
card is distinguished by a unique image that helps the agent select and identify a campaign
much faster.
One the agent clicks on one campaign; the app transforms the card into a long one by
displaying more information like the description of the steps of the enrolments that form our
workflow of phases to achieve one enrolment successfully.
Right on the bottom of the long card, the app displays the states of one specific
campaigns by informing the agents on his previous submitted enrolments situations.
 Steps Interfaces

One the agent has selected one campaign to begin the enrolment process, the app
displays all the steps that need to be taken to submit the enrolment packs, the steps can either
be a classic camera capture, an MRZ code detection, or an OCR capture scan. each time the
agents finish a step, the app redirects him to this step interface to display the remain steps or if
all steps have been executed than the agent must either save the enrolled data locally or cancel
and exit the campaign enrolment process.
 OCR and data extraction

Once the agent has selected one step, the OCR scanning procedure kick off by opening
the mobile device camera and the background rectangle detection algorithm that try to capture
in real time the physical document. once the camera has detected a rectangle pattern from the
document, the app automatically captures and crop the image of the document and starts the
OCR processing phase, finally the app displays the extracted raw data from the document and
wait for the intervention of the agent to either edit the captured data from the presented results
or directly save the information and be redirected to the first steps interfaces to continue the
enrolment process.
When the agent has fully accomplished all the steps needed for the campaign
enrolment, he can only then access the enrolment packs on hold and choose to either delete or
synch the data to our backend server to be later reviewed by an administrator.
4.5.2. Scenario 2: Admin review
Authentication interface : Backend web application

Our backend solution is our main source to go for all the configuration and CRUD
operations needed for the smooth functioning of our system, it provides the Admin a list of
multiple privileges and functions such as user management, campaign configuration,
Template configuration, enrolment review, etc.
Before accessing the system, the actor (admin/agent) must authenticate first through the
login page displayed below.

Submitted enrolment interface

Through this web interface, the system list all the submitted enrolment sorted by date, the
admin then select the enrolment pack needed to be examined.

Enrolment pack interface

The final step of the approval procedure for the administrator is to either approve or decline
the agent’s submitted pack, once the decision is make, a remote push notification is send to
the agents informing him by the final evaluation results.
4.6. Conclusion
As part of our End of Studies Project and in order to obtain an engineering degree in
computer science performed within the IRSEL company, we were asked to design and
develop a mobile enrolment system using OCR technology, by developing both a front end
mobile application and a backend web solution. We thought it appropriate to measure the
experiences of each other in this area, in order to identify the shortcomings of existing
systems and to propose an effective solution that allows us to take the client enrolment
process to next level regardless of their respective backgrounds.

During this project, we used a methodology inspired by the Unified Process "UP" is
2TUP. Modeling of this solution was performed with the UML modeling language.

This graduation project has benefited us in many ways. Indeed, it has allowed us not
only to deepen our knowledge and to acquire new information technologies but also to
formalize us with the implementation of development projects, it also offered an opportunity
to exploit and realize those new acquired for the development of an effective application. He
also contributed to the improvement of knowledge in the field of mobile development using
UML, on both theoretical and practical. It has without a doubt allowed us to highlight the
importance of computerization of information systems and dynamism they generate within
companies. We emphasize that the development of this project was very rewarding from a
technical standpoint, but also from the organizational point of view. It allowed us to practice
more theoretical knowledge. It is also undeniable that participation in the project was very
beneficial relationally. Group work has further strengthened our team spirit and our sense of
collaboration.
Although the main objectives of our project are met, the application that we developed
could be enriched with other advanced features and improvements can be envisaged for the
rich, such as Auto client enrolment, subscription systems, etc.