Tunsian Republic

Private Higher School of Engineering and Technology

INTEGRATED DEVELOPMENT PROJECT REPORT

Presented as part of the Integration Development Project

Elaborated by

Chaima Khemili

Hedi Boughanmi

Lilia Gaiji

Mariem Souilem

Taha Jelassi

Youssef Ben Romdhane

Design and development of a Web / Mobile

application for IRMC

Academic Year 2017 - 2018

 Tunisian Republic

Private Higher School of Engineering and Technology

INTEGRATED DEVELOPMENT PROJECT REPORT

Presented as part of the Integration Development Project

Elaborated by

Chaima Khemili

Hedi Boughanmi

Lilia Gaiji

Mariem Souilem

Taha Jelassi

Youssef Ben Romdhane

Design and development of a Web / Mobile

application for IRMC

Academic Year 2017 - 2018

Contents

General Introduction 1

1 Preliminary study 2
1.1 Presentation of the company . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2 Study of the existing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2.1 Critical of the existing . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2.2 Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.3 Adopted methodologies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.3.1 Choice of development method . . . . . . . . . . . . . . . . . . . . . . . 5
1.3.2 Presentation of the 2TUP methodology . . . . . . . . . . . . . . . . . . . 6

2 Analysis and requirements specification 8

2.1 Functional branch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.1.1 Capture needs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
[Link] Identification of actors . . . . . . . . . . . . . . . . . . . . . . . 9
[Link] Functional requirements . . . . . . . . . . . . . . . . . . . . . . 9
[Link] Non-functional requirements . . . . . . . . . . . . . . . . . . . . 10
2.1.2 Diagram of use cases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.1.3 Internal specifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.2 Technical Branch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.2.1 Development languages . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.2.2 Why Java ? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.2.3 Why .Net ? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.2.4 Why Web Services ? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

3 Conceptual study 17
3.1 Application Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.1.1 2-tier architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.1.2 N-tier architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.1.3 Choice of architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.2 Class diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Bibliography 21

i
List of Figures

1.1 IRMC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2 Directory of Tunisian documentation . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3 IRMC Catalog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.4 2TUP Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.1 Use Cases Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

3.1 Deployment Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

3.2 Class Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

ii
List of Tables

2.1 Internal specifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

iii
List of abbreviations

• 2TUP = Two Track Unified Process

• IRMC = Institute Research Contemporary Maghreb

iv
General Introduction

Nowadays technology brought forth a worldwide revolution in every aspect of our lives. This
notion affected us either directly or remotely by numeric technologies, and the effect is growing
exponentially every day. So, to cope with these changes, traditional ways of doing things are
getting rarer.
In this context many companies and other entities are switching their desks and buildings
to computer based on applications and servers, where they can execute the exact same tasks
with much less resources, expenses and time.
Esprit students of information technology are honored today to apply their knowledge in
several developing technologies in order to embody the idea of our client which aims to create
an application that manage sinister claims, delivering to the beneficiary of services the ability
to create in real time a sinister in an online platform from his available device, the process must
be secured and reliable.
In this project we must also be able to work in group, and to apply the 2TUP method to
organize our efforts, divide our project to sprints, and to assess the advancement of our work.

1
 Chapter 1

Preliminary study

Outline
1 Presentation of the company . . . . . . . . . . . . . . . . . . . . . . . 3

2 Study of the existing . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

3 Adopted methodologies . . . . . . . . . . . . . . . . . . . . . . . . . . 5
Chapter 1. Preliminary study

Introduction
In this first chapter we present the company. We will also mention the motivations that
motivated us to do this project and we will explain the problem and the objectives set. We will
discuss the solutions proposed to meet these objectives.

1.1 Presentation of the company

The Institute for Research on Contemporary Maghreb (IRMC) is a research center in the
humanities and social sciences, with a regional vocation, based in Tunis. It is one of the 27
French research institutes abroad (IFRE) and is under the supervision of the Ministry of Foreign
and European Affairs and, since 2000, the Ministry of Higher Education and Research, and the
National Center for Scientific Research (CNRS) of which it constitutes a mixed unit (USR
3077)

Figure 1.1: IRMC

3
Chapter 1. Preliminary study

1.2 Study of the existing

The directory of Tunisian documentation centers is an online tool offered by the IRMC’s
Documentation Services . Listening a hundred documentary structures via individual data
sheets (type, domains, access, contact, etc.) and a geolocation system, this service is accessible
to any user; Its objective is to overcome the lack of a directory of documentary structures in
Tunisia.
The computerization of the fund started in 1987. Regular acquisitions during the 1980s
have made it possible to update the research work, and to bring together Tunisian or Maghreb
and Arabian university publications.
The computerized catalog contains descriptions of books and brochures (28,500 books),
articles of journals and collective works and titles of periodicals (including 90 subscriptions).
The computerized catalog that is used in 2018 is lacking details and new technologies tools.

1.2.1 Critical of the existing

However, The IRMC’s documentation services is using Excel Although in the majority
of cases, Excel remains the most appropriate tool to achieve some precise tasks: allows a
great flexibility and offers a remarkable degree of automation ... However, poorly used, it can
introduce considerable administrative red tape: broken formulas, miscalculations that lead to
decisions based on bad information, less secure, bugs encountered when processing large files,
the fact that only one user can use it at a time, not dynamic ...

Figure 1.2: Directory of Tunisian documentation

4
Chapter 1. Preliminary study

Figure 1.3: IRMC Catalog

1.2.2 Objectives

In order to correct the anomalies mentioned above and to meet the needs of the users, we
propose to design an application offering the user a better directory service as well as the fast,
efficient handling of IRMC informations

1.3 Adopted methodologies

A software engineering methodology refers to all stages and their sequence in the process of
developing a computer application. Its purpose is to enable ensure compliance between business
needs, application code and product final.
For this reason we must adopt a development methodology that we are going to respect
throughout the project to achieve our application. Today the object modeling industry standard
is UML (Unified Modeling Language). UML is defined as a graphical and textual modeling
language. Our choice was unified process oriented (PU or UP for Unified Process) as a method
of development.
The unified process is iterative and inertial, driven by use cases, focused on architecture
and risk-oriented

1.3.1 Choice of development method

In order to control the risks and bring our project to a successful conclusion due to its
complexity, we have opted for the 2TUP process that follows the Y-life cycle for several reasons.
In fact the 2TUP gives great importance to the technology which is important for our project.

5
Chapter 1. Preliminary study

1.3.2 Presentation of the 2TUP methodology

2TUP (2 tracks unified process), or T2UP, is a software development process that imple-
ments the Unified process method. 2TUP proposes a development cycle in Y, which dissociates
the technical aspects of the functional aspects. Therefore, if the technology evolves during the
course of the project, if there is a modification technical need, the technical branch can be
treated and then reintegrated into the project easily. Similarly, if a new feature arises, only the
functional branch will be treated without touching the other limb. From Figure 1.4, we will

Figure 1.4: 2TUP Methodology

notice that 2TUP is essentially composed of three steps :

• a functional branch: which is based on information gathering, understanding of the busi-

ness and the capture of business needs;

• a technical branch: which capitalizes the technical know-how and / or constraints These
techniques are independent of the functions to be performed;

• The implementation phase: it brings together the two branches, in order to deliver an
adapted to needs.

6
Chapter 1. Preliminary study

Conclusion
In this chapter we have presented the company, the critical study of the existing and specify
the methodology to follow to meet our needs. In the next chapter we will define the functional
branch of the 2TUP method that will be used to put the project in context.

7
 Chapter 2

Analysis and requirements

specification

Outline
1 Functional branch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2 Technical Branch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Chapter 2. Analysis and requirements specification

Introduction
In this chapter, we will first present the main actors and their roles. Then we define the
functional and non-functional needs of the application in the functional branch. Then we will
present the system use case diagram. Finally, we will present the second branch of methodology
namely the technical branch

2.1 Functional branch

2.1.1 Capture needs

[Link] Identification of actors

• Webmaster : This is the main actor. He has all the rights of access. He must be able
consult, modify and delete libraries, research Centers, searchers. He has the possibility
Add, delete, and approve events, job offers, scolarships and proposed searchers. The
administrator is the only one who can add,modify, delete videos and reviews. Consult
the history of the operations made on the application and manage other users;

• Guest : This actor can search or consult libraries, research Centers on the map, suggest
and consult scolarships and job offers. Consult and research reviews and watch videos
and video-conferences;

• Searcher : He has the same privileges as the guest with extra advantages like being
involved in a team of searches within a colaborative space.

[Link] Functional requirements

The functional requirements come from the specifications of the project. These are the
required needs by the end user. They are the features and actions that the system must
obligatorily carry out.
The application must meet the following functional requirements:

• Management of research centers : The system should allow users to consult the list of
diffrent research centers on map and allow editing and deleting for users with permissions
required;

• Event management : The system should allow users to consult the list of Events (Scolar-
ships, Job proposals) with the possibility to collect diffrent events from various resources,

9
Chapter 2. Analysis and requirements specification

search and filter existing events according to all available criteria and allow editing and
deleting for users having the required permissions;

• User Management : User management is an essential need for the security of the applica-
tion. The system should allow users with the required permissions to approve other users
and grant them specified roles;

• Domain management of research centers : The system should allow the webmaster to
add, modify, delete and assign diffrent domains to specefic research centers;

• Management of videos and documents : The system should allow the webmaster to add,
modify, delete and index videos and documents.

[Link] Non-functional requirements

Non-functional requirements are requirements that do not specifically concern the system
behavior. These needs are not explicitly requested by the user, they contribute to the improve-
ment of applciation such as safety, reliability, maintainability and extensibility. The application
must meet the following non-functional needs:

• Performance : Because of the large amount of data, the application must be efficient and
respond to user requests in minimal time;

• Ergonomics : The application must be easy to access and does not require a time learning.
It will have simple interfaces, ergonomic and easy to use;

• Security : The application must be secured against unauthorized action.

10
Chapter 2. Analysis and requirements specification

2.1.2 Diagram of use cases

After the specification of the functional requirements of the users, we will present themain
features of the system as a use cases that identifies the actors who interact with this system
while clarifying their roles.
Figure 2.1 illustrates the general use case diagram of our system, We will notice the inclusion
links that link the different use cases, which shows that the use case they are heading to should
be executed. first.

11
Chapter 2. Analysis and requirements specification

Figure 2.1: Use Cases Diagram

12
Chapter 2. Analysis and requirements specification

2.1.3 Internal specifications

Technology Module Code Functional re- Assigned

quirments to
JEE01 Create new event
JEE02 Update event
Event Management JEE03 Remove event
JEE04 Consult events
JEE05 Collect events with
RSS
JEE06 Create new center
JEE07 Update center
JEE08 Remove center
Research Centres Management
JEE09 Consult center
JEE10 Search for centres
JEE11 Allocate centres on
Map
JEE
JEE12 Create new user
JEE13 Update user
User management
JEE14 Remove user
JEE15 Approve user
JEE16 Create new do-
main
Domain management
JEE17 Update domain
JEE18 Remove domain
JEE19 Sort domain with
most centres
JEE20 Upload a new
Video management video
JEE21 Update a video
JEE22 Archive a video
JEE23 Upload a docu-
ment
Document management

13
Chapter 2. Analysis and requirements specification

JEE24 Share a document

JEE25 Archive a docu-
ment
JEE26 Delete a document
Mob01 Search for events
Event Management Mob02 Consult events
Mob03 Locate events on
map
Mob04 Search for centres
Research Centres Management Mob05 Locate centres on
map
Mobile
Mob06 contact centres
Mob07 Consult other
User management
searchers profile
Mob08 Manage profile
Mob09 Consult docu-
Document management
ments
Mob10 Add to favorites
Mob11 Consult videos
Video management
Mob12 Add to favorite
playlist
Mob13 Consult available
Domain management
domains
Mob14 Sort domain with
different criteria
.NET .NET01 Asign research cen-
Research Centres Management ter to a domain
.NET02 Approve proposal
for extra domains
.NET03 Collect informa-
tion with flux
RSS

14
Chapter 2. Analysis and requirements specification

.NET04 Consult event

Event Management
statistics
.NET05 Approve events
.NET06 Contact user
User management .NET07 Assign user to a
team of searchers
.NET08 Manage profile
.NET09 Add a tag to a doc-
Document management ument
.NET10 List document by a
specific tag
.NET11 Search for docu-
ment by different
criteria
.NET12 Search for video by
different criteria
Video management
.NET13 Assign tags for
videos
.NET14 Archive videos
.NET15 Index videos by
themes

Table 2.1: Internal specifications

15
Chapter 2. Analysis and requirements specification

2.2 Technical Branch

The Technical Study is an essential step in the 2TUP method, in this step we have to choose
the best technologies that lead us to realize the application and reach the customer needs. We
chose JAVA to develop web services and consume them later on other plateform, in our case
.Net and mobile application.

2.2.1 Development languages

2.2.2 Why Java ?

We chose JAVA as the language to develop the web services of the application. First of all
JAVA is portable, so just install the JVM on the deploy machine for the application to work,
then the popularity of this language increases our chance of find solutions quickly to problems
encountered during the development phase.

2.2.3 Why .Net ?

Developing applications using .Net framework is very robust and highly secure with great
quality. .Net platform reduces development time, creates quality, reliable, and scalable applica-
tions that ensure smooth functioning of complex business applications. Hence it helps customer
to improve their business easily.

2.2.4 Why Web Services ?

REST Services are very important for us to minimize the coupling between client and server
components in a distributed application.
This may be our case also when the server is going to be used by many different clients that
we do not have control over. It’s also the case when we want to update the server regularly
without needing to update the client software.

Conclusion
In this chapter we have specified the needs to which our system must respond, this which
was helpful to us to show our purpose and needs. Finally, we still have to develop a good design
to ensure the proper functioning of the system. That’s how we can start the next chapter on
step-by-step design safe.

16
 Chapter 3

Conceptual study

Outline
1 Application Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 18

2 Class diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Chapter 3. Conceptual study

Introduction
In this chapter, we will present the architecture of the application and then we will move
at the system design stage which will be illustrated by the class diagram.

3.1 Application Architecture

In this step, we will merge the functional branch and the technical branch.

3.1.1 2-tier architecture

In a 2-tier architecture, still called client-server, the client machine is content to delegate
data management to a specialized service. This type of application makes it possible to the
power of computers deployed in a network to provide the user with a rich interface, while
ensuring data consistency, which remains centrally managed.

3.1.2 N-tier architecture

The N-tier architecture is composed of three elements, or more precisely three layers. Indeed,
it is more appropriate to speak of functional layer where each of them is attached an element
/ logical entity.
In the 3-tier model or N-tier, three layers must be distinguished:

• The presentation layer (or display) associated with the customer that is actually "light"
in the since it does not assume any processing functions unlike the Client / model Server
or 2-tier;

• The functional layer linked to the server, includes the application server or server inter-
mediary, which in many cases is a web server with application extensions;

• The data layer linked to the database server (DBMS).

3.1.3 Choice of architecture

Our choice fell on the N-tier architecture for the following reasons:

• Since our client must be lightweight and only have to connect to the server, we chose a
more advanced architecture than 2-tier architecture;

• This architecture is much more flexible than 2-tier architecture.

18
Chapter 3. Conceptual study

Our application is service oriented, it is composed of a MYSQL database, by a .NET application

and a JAVA application that contains a set of web services who will be queried by .Net and
mobile Clients.
Figure 3.1 shows the architecture of the application.

Figure 3.1: Deployment Diagram

19
Chapter 3. Conceptual study

3.2 Class diagram

The class diagram presents the central point in an object-oriented development. In analysis,
it aims to describe the structure of entities handled by users.

Figure 3.2: Class Diagram

Conclusion
During this chapter we realized the design that encompasses all the features major to achieve.
The need for such a study is very useful during the implementation phase.

20
Bibliography

[1] Staackoverflow
[Link]

[2] knowtex
[Link]

21