Elaborated by : Supervised by :

Chalghoumi Najoua Ms Khiari syrines

Bakir Mohamed El Khamed

Design And

Implementation Of An

Examination

Management Application

For ESPRIT

End Of Year Project

Academic Year 2011-2012

Dedications

In the memory of our loved grandmothers

To our fathers

To our dear mothers

To our brothers

To our sisters

To all our families

And all who loved us and whom we love

We dedicate this work….

Abstract

This report details the work done by us on our end of year project and it was held from

December 2011 to April 2012.The purpose of this work consist of the Establishment of

an informatics solution that ensure organization and management of exams in our

university ‘’ESPRIT’’. The application is assumed to automate the complete cycle of

examination management. In other terms, our system revolutionizes the entire traditional

examination process by diligently meeting the requirements of our university. In fact, these

systems insure acceleration and more precision during the examination management.

However, our university cannot afford to invest huge sums in expensive commercial

software that can automate the examination cycle. In this context, Microsoft technologies

such .Net framework, BizTalk server 2010, MySQL Server 2008 are used in our project in

order to implement a web-based tool which exactly models the university’s needs by

computerizing the required steps already excepted by the system and enabling users to

manage examination process awards error free.

Acknowledgement

In term of this work, we would like, first and foremost, to express our gratitude and

acknowledgement for our supervisor Ms Syrine Khiari, for her permanent support and her

encouragement. Her continuous guidance and precious advices made an important contribution

for the successful achievement of this work.

All our thanks and our great recognition to all our professors and teachers during for the

formation that they gave us within the ESPRIT. They were an inexhaustible source of learning.

Special thank goes to our mothers for their continuous support, their patience and their affection,

and to all our families’ members.

Lastly, we offer our regards and blessings to all of those who supported us in any respect during

the completion of this project.

Table of contents

GENELRAL

Introduction 1

CHAPTER 1 :CONTEXT OF THE PROJECT.............................................................................2

INTRODUCTION......................................................................................................................................2

1. PROBLEMATIC................................................................................................................................2

2. SOLUTION......................................................................................................................................3

CONCLUSION.........................................................................................................................................3

CHAPTER 2 : STATE OF THE ART.............................................................................................4

INTRODUCTION......................................................................................................................................4

1. KEY CONCEPTS..............................................................................................................................4

2. STUDY OF THE EXISTING..............................................................................................................11

a. Study of the current situation..............................................................................................11

b. Problematic........................................................................................................................12

c. Current situation in jendouba university............................................................................13

d. Tools on the market............................................................................................................13

3. METHODOLOGIE AN CYCLE OF DEVLOPMENT.............................................................................16

CONCLUSION.......................................................................................................................................19

CHAPTER 3 :ANALYSIS AND SPECIFICATION OF REQUIREMENTS...........................20

INTRODUCTION....................................................................................................................................20

1. FUNCTIONAL REQUIREMENTS......................................................................................................20

2. NON-FUNCTIONAL REQUIREMENTS.............................................................................................21

3. GENELRAL USE CASE DIAGRAM..................................................................................................21

4. DESCRIPTION OF USE CASE..........................................................................................................22

CONCLUSION.......................................................................................................................................25

CHAPTER 4 : DESIGN..................................................................................................................26

INTRODUCTION....................................................................................................................................26

1. CONCEPTUAL CHOICES................................................................................................................26

Choices of architecture.......................................................................................................26

2. CLASS DIAGRAM.........................................................................................................................28

3. DETAILLED DESIGN......................................................................................................................29

a. Sequence diagram...............................................................................................................30

b. Activity diagram.................................................................................................................32

c. State machine diagram.......................................................................................................34

CONCLUSION.......................................................................................................................................35

CHAPTER 5: IMPLEMENTATION............................................................................................36

INTRODUCTION....................................................................................................................................36

1. DEVLOPMENT ENVIRONMENT......................................................................................................36

a. Hardware environment.......................................................................................................36

b. Software environment.........................................................................................................36

2 . IMPLEMENTATION.......................................................................................................................39

a. Results in biztalk testing.....................................................................................................39

b. Site Map..............................................................................................................................40

c. Web pages...........................................................................................................................41

CONCLUSION.......................................................................................................................................44

GENARAL CONCLUSION...........................................................................................................45

APPENDIX:.....................................................................................................................................46

WEBOGRAPHIE:...........................................................................................................................56

BIBLIOGRAPHIE :........................................................................................................................56

List of figures

FIGURE 1 : SPAGHETIS ARCHITECTURES

FIGURE 2 : THE BPM FUNCTIONALITIES

FIGURE 3 : THE ENTREPRISE SERVICE BUS

FIGURE 4 : BIZTALK COMPONENTS

FIGURE 5 :BIZTALK ENGINE COMPONENTS

FIGURE 6 :EXAMINATION SYSTEM OF JENDOUBA UNIVERSITY

FIGURE 7 :ORGANET MANAGEMENT SYSTEM

FIGURE 8 : EDUSOFT EXAMINATION MANAGEMENT

FIGURE 9 : SCRUM METHODOLOGY

FIGURE 10 : THE WORK MADE DURING EACH SRINT

FIGURE 11 : USE CASE DIAGRAM

FIGURE 12 : THE APPLICATION ARCHITECTURE

FIGURE 13 :CLASS DIAGRAM

FIGURE 14 : SEQUENCE DIAGRAM “VIEW SCHEDULE”

FIGURE 15 : SEQUENCE DIAGRAM “ADD TEST”

FIGURE 16 : SEQUENCE DIAGRAM “UPDATE CLASSROOM”

FIGURE 17 : ACTIVITY DIAGRAM “AFFECT SUPERVISOR”

FIGURE 18 : ACTIVITY DIAGRAM “DISAFFECT CLASSROOM”

FIGURE 19 : ACTIVITY DIAGRAM “VIEW SCHEDULE”

FIGURE 20 : STATE MACHINE DIAGRAM “CLASS CLASSROOM”

FIGURE 21 : SELECT SUPERVISOR ORCHESTRATION

FIGURE 22 :INSERT SUPERVISOR ORCHESTRATION

FIGURE 23 :SITE MAP

FIGURE 24 :HOME PAGE

FIGURE 25 : ADMINISTRATOR UTHENTICATION

FIGURE 26 : CLASSROOMS MNAGEMENT

FIGURE 27 : SUPERVISORS MANAGEMENT

ESPRIT 2011/2012

General introduction

With the advent of technology and continuous students’ number increase the education

systems are becoming complex and now it is not an easy job to manage them manually. ESPRIT

University came to strengthen the national system of engineering studies in Tunisia and now it is

ranked among the first class institutions of the country. In the beginning number of students

enrolled in the university was limited but now this number increases and reaches 2000 students and

this increase has sophisticated the process of Examination Management. In the past there is no any

computerized system to manage examination especially pre-examination activities. All the work is

done on manual basis and there are many people who are working day and night to maintain the

examination system of university. There is no formal existing computer system but it can be said

that such type of systems are indispensable nowadays. Lack of technologies used in pre-

examination activities obstructs dealing with it in a modern and simplified way. In this context, our

end of year project which aims to establish an all in one solution that ensure managing examination

system. The main outcome of this project is to computerize everything related to examination’s

pre-activities. So we are going to study the new system requirements, analyze it, design, implement

and finally test and integrate it in ESPRIT. This report is split into 5 chapters. Each chapter deals

with a separate part of the project evolution as follows:

Chapter 1 We are going to point out why we have to make such a project into existence by

defining the problematic and describing the appropriate solution.

Chapter 2 We are going to set an overall of the concepts and the tools required for the solution.

Then we are going to study the existing

Chapter 3 We are going to define requirements that we should remedy thanks to this project

Chapter 4 We are going to pursue the phase of design by basing itself in the language of

modeling UML.

Chapter 5 We are going to mention technical aspects this project allows us to learn and we are

going to present screen shots of our application.

At the end of the work, conclusion is done and suggestions for future work are given.

1

ESPRIT 2011/2012

Chapter 1: Context of the project

Introduction

In this chapter we are going to talk about the goal of our end of year project.

We will start with treating the problematic in order to identify the problems that ESPRIT suffers

from. Then, we will describe the solution that we advocate curing the identified weaknesses.

1. Problematic

The management examination’s pre-activities in ESPRIT need a lot of documents and

time because it is based on manual approach and it is extremely difficult to the agent in

charge of this to do all these tedious examinations management tasks.

Following are some drawbacks of manual work:

Time consuming:

Getting the required information from the available data takes a lot of time. Changing,

editing and updating the information contained in several files are slow and time

consuming process.

Needs Large Space:

In manual work done data item has to be stored at several places. So, it requires more

storage space

Data Security:

There is no security in the manual work. Data can be damaged or lost and unauthorized

persons can access it easily.

Need of Effort:

In manual system, a student’s record is maintained in separate files so it takes much effort

to collect data from several files for each student and if we want to change or delete the

data of any student then it has to be changed or deleted from all the files and places.

2

ESPRIT 2011/2012

Need of Several People:

Several people are required to manage the information. This also increases the system

costs.

Errors:

There is chance for more manual errors.

2. Solution

Having mentioned the problems identified, we now addressed the solution that we believe

meet the needs of ESPRIT. The major objectives of our purposed system are to solve the

problems of the existing system. All this system is streamlined to rectify the problems of

the existing system. In fact the whole examination system is a complex and sensitive

process in which each and every step is of crucial nature and requires high level of

accuracy and perfection. So we are going to release an application which accomplish all

the tasks in a very perfect manner, minimize the work of the person in charge of

examination management and reduce obstacles which can arise during this process. In

other words, this project consists of the specification, the implementation and the

integration of an application in the information system of ESPRIT allowing of realizing an

examination management system. So, the objective of our work is to improve the existing

system of examination manage of the university by computerize it. This application has to

be at once supple and powerful to be integrated into the intranet of the university.

This application has to provide several features like:

Schedule exams

Distribute classrooms

Distribute supervisors

Manage users’ accounts

Arrange classes

Conclusions

In this introductive chapter we have exposed the problems that ESPRIT is facing.

Then we suggested a solution which consists of the development of examination management

software.

3

ESPRIT 2011/2012

Chapter 2: State of the art

Introduction

In this chapter we are going to clarify some concepts and define some tools required for the

solution mentioned in the previous chapter. Then we will describe the existing system and the cycle

of development chosen.

1. Key concepts

Here are briefly the important concepts that must be clarified before starting our project:

Spaghettis Architecture

This Spaghetti architecture was used in the past to depict application integration

before EAI (ESB). Consider the situation in Figure 1; each department builds its

own systems. The result is isolated or stovepipe systems, as new business

requirements emerged. Then, systems needed to share data, and new point-to-

point interfaces were added to solve the integration needs. As people use the

systems, they find that they need information from other systems, and point-to-

point integration emerges. There are many types of point-to-point integrations:

ETL (extract, transform Load), which is a DB-to-DB relationship; online and file-

based, both of which are application-to-application relationships; and direct

connection to a DB, which is an application-to-database relationship. Note that

this is not an exhaustive list; there are additional relation types, such as

replication, message-based, and others that are not expressed in Figure 1.

The end result is spaghetti of systems. This architecture has the following

drawbacks:

The development architecture is too expensive

4

ESPRIT 2011/2012

Expensive systems regarding multiple implementations

We need interfaces for each application

Redundant interconnections (point to point integration)

Great complexity

Hard to maintain

Figure 1: Spaghettis Architecture

BPM servers(Business Process Management servers)

They are called also supporting orchestration. They are a style of servers which

created to support the orchestrations that the shift of services implies.From a

service-oriented perspective, the goal of a BPM server is plain: it should provide

the right foundation for orchestrations that drive composite applications. To

achieve this goal, several different streams of technology have come together.

They include the following:

SOA service-oriented architecture

(EAI) enterprise application integration

(B2B) business-to-business

5

ESPRIT 2011/2012

This kind of application can be challenging to maintain, given the diverse

technologies it relies on and its inherently distributed nature. Performance might

also be a concern, especially for web services interactions in very high volume

scenarios. As with other technologies, using this approach makes sense only

when it’s the best solution for the business problem at hand. Real business

processes are seldom simple. The orchestration that drives a service based

process might access several applications, run for hours, day, or weeks,

implement complex business rules, interact with many different people, and

more. To support all of this, a BPM server must provide a diverse set of

technologies and tools. The figure below illustrates what a typical BPM server

provides and how its pieces fit together.

Figure 2: The BPM functionalities

ESB (Enterprise Service Bus)

An enterprise service bus (ESB) is a software architecture for middleware that provides

fundamental services for more complex architectures. For example, an ESB incorporates the

features required to implement a service-oriented architecture (SOA). In a general sense, an

ESB can be thought of as a mechanism that manages access to applications and services

(especially legacy versions) to present a single, simple, and consistent interface to end-users

via Web- or forms-based client-side front ends. In essence, ESB does for distributed

6

ESPRIT 2011/2012

heterogeneous back end services and applications and distributed heterogeneous front-end

users and information consumers what middleware is really supposed to do: hide complexity,

simplify access, allow developers to use generic, canonical forms of query, access and

interaction, handling the complex details in the background. The key to ESB's appeal, and

possibly also its future success, lies in its ability to support incremental service and application

integration as driven by business requirements, not as governed by available technology. This

technology provides many services as shown in the following figure:

Communication middleware supporting a variety of protocols, qualities of service, APIs, platforms, and standard protocols. A mechanism for injecting intelligent processing of service requests and responses within the network. Standard-based tools for enabling rapid integration of services. A management system for loosely-coupled applications and their interactions.

Figure 3: The Enterprise Service Bus

While the emerging research on ESB enumerates a wide range of needed

capabilities, the minimum capabilities required for an ESB to implement a SOA

design include the following:

7

ESPRIT 2011/2012

To facilitate effective service communication, the ESB provides location-

transparent routing and addressing services, service addressing and naming

administration, support at least one messaging paradigm and transport protocol.

To facilitate effective service integration, the ESB supports multiple

integration mechanisms, including connectors, web services, messaging, and

adaptors.

To facilitate effective service interaction, the ESB provides an open service

messaging and interfacing model that isolates implementations from routing

services and transport protocols, and allows implementations to be substituted.

EAI (Enterprise Application Integration)

Refers to various techniques that are used to make information systems work

together in the large enterprise. For example, when companies acquire other

companies, disparate systems have to be integrated. Within a company, newly

developed systems must work with legacy systems, and separate systems

developed independently in the past must often be tied together to provide required

information and services. When information systems are integrated, business

intelligence can be gleaned across the entire enterprise.

EAI software may function as a central distribution hub, providing data and

command conversions where necessary between applications. It is also a major

component of a business process management suite (BPM). See middleware and

application integration. EAI often entails conversion from one format to another

and differs from EII (enterprise information integration), which aggregates current

information from disparate sources.

BIZTALK

Software from Microsoft that provides integration between business processes within an

enterprise and between different organizations. In other word, it allows connecting diverse

software, then graphically creating and modifying process logic that uses that software. The

product also lets information workers monitor running processes, interact with trading

partners, and perform other business-oriented tasks. BizTalk Server uses protocol

implementations called "adapters" to communicate with applications and includes built-in

adapters and a framework for creating new ones. It also provides rules-based routing,

conversion between data formats and serves as a protocol bridge between HTTP, SMTP,

MQSeries and other applications. BizTalk Server supports the Web Services Business Process

8

ESPRIT 2011/2012

Execution Language (WSBPEL). Biztalk combine different systems into an effective business

processes; include a range of technologies.

The figure below illustrates the product’s major components:

Figure 4: Biztalk components

As the figure suggests, the heart of the product is the BizTalk Server Engine. The

engine has two main parts:

A messaging component that provides the ability to communicate with a

range of other software. By relying on pluggable adapters for different kinds of

communication, the engine can support a variety of protocols and data format s,

including web services and many others.

Orchestrations which is a support for creating and running graphically-

defined processes. Built on top of the engine’s messaging components,

orchestrations implement the logic that drives all or part of a business process.

9

ESPRIT 2011/2012

Several other technologies can also be used in concert with the engine, including:

A Business Rules Engine that allows evaluating complex sets of rules.

A Health and Activity Tracking too l that lets developers and

administrators monitor and manage the engine and the orchestrations it runs.

An Enterprise Single Sign-on facility, providing the ability to map

authentication information between Windows and non-Windows systems.

On top of this foundation, BizTalk Server provides a group of technologies that

address the more business-oriented needs of information workers. Those

technologies are:

Business Activity Monitoring, allowing information workers to monitor a

running business process. The information is displayed in business rather than

technical terms, and what gets displayed can be controlled directly by business

people.

Business Activity Services, allowing information workers to set up and

manage interactions with trading partners.

All of these technologies are focused on solving the problems inherent in using

a diverse set of software to support auto mated business processes.

To allow its users to create a business process that spans multiple applications,

the BizTalk Server engine must provide two primary things: a way to specify

and implement the logic driving that business process, and some mechanism for

communicating between the applications the business process uses. The figure

below illustrates the main components of the engine that address these two

problems.

10

ESPRIT 2011/2012

2.

3.

4.

11

ESPRIT 2011/2012

Figure 5: BizTalk Server engine components

2. Study of the existing

a. Study of the current situation

At present, the management of exams in ESPRIT is split into two parts:

Computerized part

Manually part

Beginning with the computerized part, it consists of a small application which allows

giving the map of classrooms in ESPRIT. Then all the rest of work is manually made.

In fact, after receiving lists of groups and their exams, the person in charge of

Examination management must allocate to each exam a classroom and a supervisor in

accordance with the time table of exams. This work is very complex and sophisticated

due to the fact that several constraints are taken into consideration:

Divide all classes into two groups.

All groups which are going to pass the same examination’s subject have to

take their examination in a single date.

A group mustn’t pass more than two examinations per day (maximum of

exams per day is two). One must be in the morning and the other must be in

the afternoon.

A classroom mustn’t be affected to two groups at the same time.

A supervisor mustn’t supervise nor his subject neither his group.

A supervisor mustn’t supervise twice per day.

12

ESPRIT 2011/2012

b. Problematic

From the study mentioned above we find many bottlenecks in the existing system and

these provide us a base to work on the purposed computerized examination management

system. The bottlenecks we find from the system are following:

 The maintenance of the manual data is very difficult.

Lot of time is required to perform each activity.

Chances of errors and redundancies are very high due to the complexity of the

work.

Low security of data

Therefore we conclude that the current existing system contains many incapacities and do

not satisfy all requirements of an Examination Management system.

c. Current situation in Jendouba university

This system allows creating examination schedule, affecting supervisors to classrooms

and managing classes. This program has been tested in Jendouba University and he has

been operational for 4 years.

13

ESPRIT 2011/2012

Figure 6: Examination management system of Jendouba university

d. Tools on the market

A little internet searches on Examination Management system tools show that there are

numerous tools that already exist on the market. We mention:

ORGANET

ORGANET Management System is an excellent exam management software that

can be effectively used to create examination schedules. Students and teachers have

profile-based access to the schedule. Based on the grade in which a group of

students are and the subjects they study, examination-related timetable is generated

through this school exam management system. This exam management portal also

takes into account those practical exams that have to be lined at the end of the

examination schedule.

14

ESPRIT 2011/2012

Figure 7: ORGANET Management System

Edusof examination management

Edusoft examination management is dedicated to improving the school

examination management and handles all the system related to. It allows to

customize the School examination’s activities to the specific needs required.

This application is complete is highly stable, multi-tasking, feature rich,

customizable, integrated, user friendly, with quick accurate information retrieval.

 It is that all the exam and marks management, class and subject scheduling, fee

charge and Receive, Room allocation and supervisors management.

15

ESPRIT 2011/2012

Figure 8: Edusoft Examination Management

Critic of those tools

The main disadvantages of these tools are its cost and complexity. In fact, these pieces of

software are very expensive and take an inordinate amount of money to acquire and

operate. So, ESPRIT cannot afford to them. Besides, they are not simple or easy to use.

Therefore, administrators must dedicate a certain amount of time to learn how to use

these systems. Furthermore, these systems need to be upgraded to changes in software.

Indeed, there are no guaranties that Examination management systems purchased today

will work in 3 or 4 years without a developer spending on upgrades to make it compatible

with technology changes. New version of windows, server software and office software

will impact on theirs functionalities. We conclude that none of these tools may be

perfectly adequate and suitable for ESPRIT.

16

ESPRIT 2011/2012

3. Methodology and cycle of development:

As methodology, we employ scrum to the development of project. Scrum is an agile

framework for completing complex projects. Simply put, scrum is a software

development process that helps teams respond to the unpredictability of building software

through incremental and iterative work cadences known as sprints. As opposed to a full

process or methodology like the waterfall software process model, it is a framework. So

instead of providing complete, detailed descriptions of how everything is to be done on

the project, much is left up to the team. This is done because the team will know best how

to solve its problem.

How does Scrum work?

The key features of the Scrum framework are as follows:

- The desired outcomes/features of the project are organized into a dynamic list called a

product backlog.

Items may be deleted or added at any time during the project.

Items are kept priority order.

Lower priority items are intentionally course-‐grained.

- Teams work in cycles called sprints, iterations that typically range from two to four

weeks in duration.

- At the beginning of each sprint, teams perform sprint planning, where they choose items

to work on during the sprint, called a sprint backlog.

A sprint backlog is a negotiated set of items from the product backlog that a team

commits to complete during the time-box of a sprint.

Items in the sprint backlog are broken into detailed tasks for the team members to

complete.

The team works collaboratively to complete items in the sprint backlog, meeting

each day (daily scrum) to share struggles and progress and update the sprint

backlog and burn down chart accordingly.

17

ESPRIT 2011/2012

- At the end of each sprint, the team delivers a potentially shippable increment of work,

presented during a sprint review.

Potentially shippable means that the increment/deliverable could be released to a

customer.

The product owner makes the decision about when to actually release any

functionality or deliverable.

The team takes the time at the end of every sprint to identify ways to improve

both the end product and the process in future sprints. This ceremony is known as

the sprint retrospective.

- The cycle repeats until enough items in the product backlog have been completed, the

budget is depleted, or a deadline arrives.

Which of these milestones marks the end of the work is entirely specific to the project.

No matter which impetus stops work, Scrum ensures that the most valuable work has

been completed when the project ends.

Figure 9: Scrum methodology

18

ESPRIT 2011/2012

Our work is split into 4 Sprints in each sprint we have to do many tasks as follows:

Sprint1: Design

Draw general uses case and describe each use case

Draw sequence diagram and describe scenarios

Draw activity diagram and describe it

Draw class diagram and describe it

Sprint2: Database and Biztalk development

Design of database

Creating database

Design of orchestration

Configuring Biztalk

Sprint3:Coding

Implementing web services

Development of the asp.net web application

Sprint4:Testing und debugging

Testing

Debugging

The following activity diagram shows the work made during the development of each

sprint:

19

ESPRIT 2011/2012

Figure 10: The work made during each sprint

Conclusion

In this chapter we have clarified the important concepts related to our project study the existing

system. After that a study of existing was made and a cycle of development was chosen. The next

chapter will be devoted to the analysis and the specification of needs.

20

ESPRIT 2011/2012

Chapter 3: Analysis and specification

of requirements

Introduction

In this chapter we are going to define with precision both functional and not functional needs. In

fact, this task is among the most vital parts of the process; given that the failure to properly

identify requirements makes it virtually impossible for the finished piece of software to meet the

needs of the user or to be finished on time.

1. Functional Requirements

Functional requirements are simply what we want the system to do. They capture the

intended behavior we want the system to perform. This behavior may be expressed as

services, tasks or functions the system is required to achieve for different kinds of users or

actors. The important point to note is that what’s wanted is specified, and not how it will

be delivered. They have important implications for software architecture, and must be

taken into account when we design the solution. Our tool must provide the following

features:

Authenticate the user with the right to access the ( administrator, simple user)

An administrator will be able to:

manage accounts

manage examinations

schedule exams

arrange classes

distribute supervisors

distribute classrooms

A simple user (supervisor, student) will be able to:

Browse the application and consult information

21

ESPRIT 2011/2012

2. Non-functional requirements

In this part we are interested to the second category of our system’s requirements which

are non-functional. These requirements are not indispensable for the proper functioning of

the application but they help satisfy the needs of the user and respond better to his

expectations.

This category involves:

Simple and fast authorization in order to ensure a quick access to the application

An ergonomic and easy-use interface

An extensible application (the application must be easily modified so that it can

satisfy all new requirements of the university)

A supple (flexible) application ( this piece of software should be easily integrated

into the intranet of the university)

Constraints and controls of seizures and messages that appear after the success or

the failure of an operation

Security

3. General use case diagram

After doing the crucial task of defining the requirements of our software we are going in

this part to deal with uses case diagram which is a graphical representation that

describes how users will interact with the proposed system so as to identify excellent

requirements and partition system functionalities. We presumed, in our project design,

that we have three actors:

Administrator

Supervisor

Student

In fact, the administrator is going to manage Examinations so that both supervisors and

students will be able to see theirs examination’s timetables in order to fulfill the main

project’s goal: well Examination management.

22

ESPRIT 2011/2012

The following diagram gives an overview of the identified use cases.

Figure 11: use case diagram

4. Description of uses case

To well understand what the system does in which case, here are the use cases

corresponding to each function seen previously:

23

ESPRIT 2011/2012

Manage accounts

Use case’s name Manage accounts

Main actor Administrator

Goal in contextThe management of accounts by the administrator

Assumptions (precondition)

The administrator must have an account to access the application.The administrator must authenticate.

Successful end condition Administrator successfully authenticates and he is re-directed to manage accounts.

Fall end conditions Administrator is not able to authenticate.

Scenario (Main path)1. Log in as an administrator2. The system verify information3. The system display the administrative page4. The user select the menu option “Manage accounts”5. The user select the wanted operation (add / remove

/update)6. The system asks for confirmation7. The user confirms8. The update is done by the system

Manage Exams’ date

Use case’s name Manage exams’ date

Main actor Administrator

Goal in contextSchedule exams

Assumptions (precondition)

The user must have an account to access the application.The user must authenticate as an administrator

Successful end condition User successfully authenticate and hi sis re-directed to

24

ESPRIT 2011/2012

Fall end conditions User is not able to authenticate

Scenario (Main path )1. Log in as an administrator2. The system verify information3. The system display the administrative page4. The user select the menu option “Manage exams’

schedule”5. The user enter examinations and their date6. The system asks for confirmation7. User confirms8. Examinations are scheduled

Manage classes

Use case’s name Manage classes

Main actor Administrator

Goal in contextAffect a classroom to each group

Assumptions (precondition)

The user has an account

Successful end condition User successfully authenticate and hi sis re-directed to

Fall end conditions User is not able to authenticate

Scenario (Main path)1. Log in as an administrator2. The system verify information3. The system display the administrative page4. The user select the menu option “Manage classes”5. The user affect each group to a classroom6. The system asks for confirmation7. User confirms8. All groups are affected to classrooms

25

ESPRIT 2011/2012

Manage supervisors

Use case’s name Manage supervisors

Main actor Administrator

Goal in contextAffect a supervisor to each group

Assumptions (precondition)

The user has an account

Successful end condition User successfully authenticate and hi sis re-directed to

Fall end conditions User is not able to authenticate

Scenario (main path)1. Log in as an administrator2. The system verify information3. The system display the administrative page4. The user select the menu option “Manage supervisors”5. The user affect each supervisor to a classroom6. The system asks for confirmation7. User confirms8. All supervisors are affected to classrooms

Conclusion

In this chapter we tried to do a good set of requirements and we presented diagram of uses case in

order to specify correctly what the system should do and avoid dead-end situations.

In the next chapter we will see the detailed solution conception.

26

ESPRIT 2011/2012

Chapter 4: Design

Introduction

Further to the detailed specification of requirements, we are henceforth capable of elaborating the

complete design of the adopted solution for the Examination management System that we plan to

27

ESPRIT 2011/2012

develop. We clarify this chapter will lead us to discover some specific design features by

beginning with the classes diagram, followed by a detailed deseing. To give a better visibility of

the operating mode of the software, we finish this chapter by unrolling sequence diagrams

showing the execution of very simple scenarios, and the communication between the different

modules and objects.

1. Conceptual choices

a) Choice of architecture

We choose the n-tier approach to design our application because n-tiers systems has many advantages insofar they are more scalable, robust and flexible. It means that presentation, application object, application logic, and database layers are separated to support scalability and growth. Our application is divided into two great parts. In fact, used data in this application are stored into two separated databases: the first one is distant and belongs to ESPRIT (in this project we simulate it by a database called DB. ESPRIT); the second one called EXAM.LOCAL.DB contains data which are used locally.

Our application is split into 5 layers as follows:

The presentation layer (GUI)This layer is called graphic user interfaces which is the layer responsible for

displaying user interfaces and driving interfaces using business tiers classes and

objects. In ASP.net it includes ASPX pages, user controls and server controls.

Business object layer (POCOS)Business object layer is called also Object Mapping layer (OML) which unites many

different data sources in a common access layer. In other word, this layer encapsulates

all the entities (classes or generics) of our system.

Business Logic layer (BLL)This layer classes perform business rule data validation, assignment of properties, and

data manipulation of fields fetched from the database through the data access layer

(DAL). In other terms, it is responsible for accessing the DAL to retrieve, modify and

delete data then send the result to the presentation layer (UI).

The BLL works in conjunction with the Business Object layers. On another hand, this

layer

DATA access layer (DAL)

28

ESPRIT 2011/2012

A data access layer (DAL) is a layer which provides access to data stored in

Database.

We develop our DAL with ADO.net Entity Framework using the approach Data First

that means:

We create our database using SQL Server2008 then we use Entity Framework in order

to generate automatically a data model that consists of classes and properties that

correspond to our existing database objects such as tables and columns.

Service layer

This layer consumes WCF Services via BizTalk orchestrations and implements them

as services which are going to be consumed in their turn by the BLL.

To conclude, our application has the architecture illustrated in the following figure:

Figure 12: The application’s architecture

29

ESPRIT 2011/2012

b) Choice of framework object-relational mapping (entity framework EF)

The ADO.NET Entity Framework (EF) is object relational mapping software for

ADO.NET, used to develop applications that interact with data. It provides a mapping

between the relational database schemas and objects. This technology is helpful for

architecting, designing and developing at a conceptual level without worrying about

details. ADO.NET Entity Framework allows to program against the Entity Relationship

(Object) model, as opposed to querying against the relational database, mainly

concentrating on the data. The main benefit is to make data oriented applications

maintenance friendly

The Entity Framework provides some awesome capabilities – mapping your conceptual

schema to your data schema, isolation from the relational database and database schema,

change tracking and identity resolution, full query comprehension and optimization, and

more.

As shown in the following diagram (Data first), we work with the Entity framework using

the approach Data First.

Figure 12: EF approach data first

This approach consist on generating with the EF a data model that consists of classes and

properties that correspond to our existing database objects such as tables and columns.

30

ESPRIT 2011/2012

The information about our database structure (store schema), our data model (conceptual

model), and the mapping between them is stored in XML in an .edmx file.

c) Choice of WCF SQL adapter

WCF SQL Adapter is used to exchange data between BizTalk Server and SQL Server Database. It

helps developers execute basic queries like create, delete, update, select statements en tables by

using a specific binding which is SQLbinding. This adapter is reusable outside of BizTalk

applications by WCF or basicHTTP clients. It also support the latest data types such as XML and

SQL Server 2008 platform.

2. Preliminary design (Class diagram)

31

ESPRIT 2011/2012

In this section we are going to describe the object model of our project. UML class

diagrams to by providing an UML class diagram containing all introduced classes.

Following is the class diagram for our project.

Figure 13: Class diagram

32

ESPRIT 2011/2012

In our examination management system EMS, the front view of class diagram is shown in the

above figure. This diagram is composed from several classes and the relationship between them.

These classes are as follows:

Examination

Test

Supervisor

Classroom

Class

Group

Block

Level

User

Administrator

Séance

Using this diagram which is built and refined when the system is developed, we represent the

vocabulary of our EMS. Each class description consists of a class name, variable and methods .this

description defines also the type of each variable as well as the signature of each method.

3. Detailed design

a) Sequence diagrams

Now, we are going to give a simplified but precise idea about how our program

processes. For this issue, we are going to make use of sequence diagrams.

Sequence diagram is an UML formalism that shows the succession of interactions

between objects in time course, within the activity of the program. We will deal

with three frequent use cases of our system, namely view schedule, add test and

update classroom.

33

ESPRIT 2011/2012

View Schedule:

Figure 14: Sequence diagram “view schedule”

Add test:

Figure 15: Sequence diagram “add test”

34

ESPRIT 2011/2012

Update classroom:

Figure 16: Sequence diagram “update classroom”

b) Activity diagrams

At this part, we are going to draw some activities diagram. Through of these

diagrams, we are going to design the main functionalities of our system which are

in order: affect supervisor, disaffect classroom and view schedules.

35

ESPRIT 2011/2012

Figure 17: Activity diagram “Affect supervisor”

When the administrator starts the application, the authentication page is displayed.

He inters his login and password. If they are not correct, the system displays error

message until he puts correct data. At that moment he is redirected to the

Administrator page. He selects the menu option ’manage supervisors” therefore, he

is redirected to the supervisors’ management page. The administrator enters new

information in order to affect supervisors.

If this information exists in the data base, the system shows an error message till

36

ESPRIT 2011/2012

the administrator put new information. At that time, these new data are stored in

the data base.

Disaffect classroom:

Figure 18: Activity diagram “Disaffect classroom”

When the administrator starts the application, the authentication page is displayed.

He inters his login and password. If they are not correct, the system displays error

message until he puts correct data. At that moment he is redirected to the

Administrator page. He selects the menu option ’manage classrooms” therefore, he

is redirected to the classrooms’ management page. The administrator selects the

menu option ‘Disaffect classroom’ enter classroom. At that moment, the system

stores new this update in the data base.

37

ESPRIT 2011/2012

view schedules

Figure 19: Activity diagram “View schedule”

When the student starts the application, the authentication page is displayed. He

inters as a student in order to consult schedule. The system redirects him to the

Student page. He clicks on the view schedule link, so the examination schedule is

displayed.

c) State machine diagram

UML state machine diagrams depict the various states that an object may be in

and the transitions between those states. The following figure represents an

example state machine diagram for the Classroom class during the allocation.

The arrows in this figure represent transitions, progressions from one state to

another. For example, when a Classroom is in the editing state, it can either be

opened for change or cancelled. If the administrator validates the classroom’s

addition, the state of this class can show error message or sit can be added.

38

ESPRIT 2011/2012

Figure 20: State machine diagram “classroom class”

Conclusion

In this chapter, we detailed the simulator’s object oriented design. For this purpose, we described

the most important classes. And finally, we unrolled two sequence diagrams demonstrating the

interactions between objects via two of the most frequent use cases of the simulator, namely

messages exchanging and timer setting. Reader may notice that we relied on simplicity in the

solution exposition in this chapter as well as in the solution design.

39

ESPRIT 2011/2012

Chapter 5: Implementation

Introduction

In this chapter, we will describe the realization part and the implementation of the solution

described in the previous chapter. We will first introduce the development environment, and then

we will describe the whole examination management process through different interfaces of our

EMS solution.

1. Development environment

a) Hardware environment

In order to carry out our work we used a HP pavilion laptop DV6 with the following features:

320 GB hard drive Intel Core 2 Duo T6600 4GB RAM

b) Software environment

40

ESPRIT 2011/2012

Description: Software Ideas modeler is lightweight, easy to use and

powerful UML tool that supports all 14 diagram types

specified in UML 2.2 diagrams and a lot of other ones. It

supports also ERD diagrams, BPMN 2.0, CRC, flowcharts and

data flow diagrams.

Description: PowerDesigner is a collaborative enterprise modelling tool

produced by Sybase. PowerDesigner runs under Microsoft

Windows as a native application, and runs under Eclipse

through a plugin. PowerDesigner supports model-driven

architecture software design. PowerDesigner uses the .pdm file

format. PowerDesigner is the industry-leading business

process / data modeling software and metadata management

solution for data architecture, information architecture and

enterprise architecture.

41

ESPRIT 2011/2012

Description:BizTalk Server 2010 is Microsoft’s Integration and connectivity

server solution. It provides a solution that allows organizations to

more easily connect disparate systems. Including over 25 multi-

platform adapters and a robust messaging infrastructure, BizTalk

Server provides connectivity between core systems both inside and

outside your organization. In addition to integration functionality,

BizTalk also provides strong durable messaging, a rules engine, EDI

connectivity, Business Activity Monitoring (BAM), RFID

capabilities and IBM Host/Mainframe connectivity.

Description:Visual Studio 2010 is an integrated development

environment (IDE) from Microsoft. It is used to

develop console and graphical user interface applications

along with Windows Forms applications, web sites, web

applications, and web services in both native code together

with managed code for all platforms supported by Microsoft

Windows, Windows Mobile, Windows CE, .NET

Framework, .NET Compact Framework and Microsoft

Silverlight. This tool supports different programming

languages by means of language services, which allow the

code editor and debugger to support (to varying degrees)

nearly any programming language, provided a language-

specific service exists.

42

ESPRIT 2011/2012

Description: SQL Server 2008 SQL Server is a relational database

management system (RDBMS) from Microsoft that's

designed for the enterprise environment. SQL Server runs

on T-SQL (Transact -SQL), a set of programming extensions

from Sybase and Microsoft that add several features to

standard SQL, including transaction control, exception

and error handling, row processing, and declared variables.

This product is said to provide enhanced flexibility, scalability,

reliability, and security to database applications, and to make

them easier to create and deploy, thus reducing the complexity

and tedium involved in database management

2. Implementation

a. results in Biztalk orchestration

These are results in BizTalk orchestration; all tests were conducted using .asmx

technology stack:

43

ESPRIT 2011/2012

Figure 21: Select supervisor orchestration

44

ESPRIT 2011/2012

Figure 22: Insert supervisor orchestration

b. site map

The following figure represents the map of our site:

Figure 23: Site map

c. web pages

45

ESPRIT 2011/2012

The system was developed and implemented successfully resulting in the following set of

web pages; noting that what's listed below is a brief of the entire solution, in the

same time they provide full functionality of the overall system.

Home page

Figure 24: Home page

46

ESPRIT 2011/2012

Administrator authentication

Figure 25: Administrator authentication

This figure represents the “Administrator authentication”. In our application ,only user who have

the suitable password can accede to our tool. If the user enters a Wrong login or a wrong

password, an error message is posted and thus user can try again until he puts the right ones.

47

ESPRIT 2011/2012

Classroom management

Figure 26: Classroom management

Supervisors management

48

ESPRIT 2011/2012

Figure 27: Supervisors management

Conclusion

In this part we have given an overview of the development environment. Then, we described the

different modules of our application through the exposition of some interfaces

49

ESPRIT 2011/2012

General conclusion

Along this report, we presented the different steps of development of an Examination management

system EMS for ESPRIT. We have learnt how to make an investigation to identify problems a

company would have; we tried to understand the University needs related to the EMS use case.

We have then got inspired from some existing solutions and also from the capabilities of some

Microsoft tool such Biztalk server and .NET platform to develop our peace of software which

consist of a rigorous solution that we hope can meet the entire requirements. Such a solution led us

to learn and use.net framework and Biztalk server and to appreciate how many interesting features

Microsoft softwares can offer to customers.

This tool handles only with examination’s pre-activities and nowadays we need such a tool

which deals also with examination’s post-activities such displaying notes and grades.

In consequence it is necessary and interesting to look on the source code optimization and

extension in order build this part and establish a whole EMS that deals with all the requirements;

not only the specific ones treated in our project. This can be an obvious continuation for our work.

50

ESPRIT 2011/2012

APPENDIX

APPENDIX A: Biztalk Orchestration

BizTalk orchestration is a flexible and powerful capability that provides various services and tools

to enable you to design, automate, and manage business processes. Similar to traditional procedural

programming languages, an orchestration represents the underlying logic for processing messages.

BizTalk orchestration provides a transactional programming model that includes support for

exception handling and recovery from failed transactions. You can define two types of transactions

when creating an orchestration:

Atomic transaction. Enables a transaction to automatically role back to a previous state in case the

transaction does not successfully complete.

Long running transaction. Can span days, weeks, and longer time durations, contain nested

transactions, and use custom exception handling to recover from error scenarios.

As a result, orchestrations provide you the flexibility to define the course of action in the event of a

business process failure.

Orchestration Designer

Orchestration Designer provides a design surface that enables you to create visual representations

of your business processes. The design surface is a working canvas where you drag different shapes

from the Toolbox as shown in Figure A. The shapes correspond to the different actions that you

need to perform when processing a message. In most cases, you must configure options for each

shape that you use when you build the orchestration.

The design surface is divided into three areas: one Process Area and two Port Surfaces. The

Process Area contains shapes that describe the actual process flow of the orchestration. For

example, scope shapes helps you define transactions in a business process. A scope contains one or

more blocks. It has a body and can optionally have any number of exception-handling blocks as

well as a compensation block appended to it.

The Process Area of the design surface is flanked on both sides by Port Surfaces, which contain

only Port and Role Link shapes that interact with the send and receive shapes in the Process Area.

You can use either side (right or left) of a Port Surface to create a send or receive port. This enables

51

ESPRIT 2011/2012

you to create well-documented orchestrations that have fewer crisscrossing connectors, making

your orchestrations easier to read.

Figure A. Orchestration Designer

Steps to Develop an Orchestration

The steps for developing an orchestration are as follows:

1. Define the schemas to describe the format of the messages to be processed by the

orchestration.

2. Add and configure the shapes to represent the various actions that are required to define the

business process.

3. Define new message instances to be processed within the orchestration.

4. Define the orchestration ports to receive and send messages

5. Define and assign orchestration variables to declare and manage the data used in the

orchestration.

6. Bind the send and receive shapes to ports, and specify the physical ports that they will use.

7. Build, deploy, and test the orchestration.

52

ESPRIT 2011/2012

The BizTalk Orchestration Engine

The BizTalk orchestration run-time engine is a highly optimized service that monitors and executes

orchestrations. At run time, the BizTalk Orchestration Engine executes the files that you create

using Orchestration Designer.

The BizTalk Orchestration Engine performs the following tasks:

Creating instances of and executing orchestrations

Maintaining the state of a running orchestration instance so that it can be restored to memory when

required

Performing optimizations of running orchestrations to maximize scalability, throughput, and efficient

use of resources

Providing a reliable shutdown-and-recovery system

The orchestration engine executes orchestrations by creating individual instances of the business

process. The run-time engine coordinates these multiple instances to ensure that a response

message gets routed to the correct orchestration instance, by using a specialized routing pattern

called correlation.

Dehydration and Rehydration

When many business processes run at the same time, memory and performance can be

compromised. The BizTalk Orchestration Engine solves this problem by dehydrating and

rehydrating orchestration instances. Dehydration is the process of saving the state of an active

orchestration instance to the MessageBox database and then removing that instance from memory.

This can happen when the orchestration engine determines that an instance has been idle for a

period of time. Dehydrating the instance frees up the resources that were being used by the

instance.

Dehydration

The orchestration engine calculates thresholds to determine how long an orchestration will wait for

various actions to take place, and if those thresholds are exceeded, it dehydrates the instance. This

can occur under the following circumstances:

When the orchestration is waiting to receive a message and the wait is longer than a threshold

determined by the engine.

When the orchestration is waiting for a subscribed message.

When a delay in the orchestration is longer than a threshold determined by the engine.

Between the retries of an atomic transaction.

The orchestration engine saves the entire state of a running orchestration instance to persistent

storage at various points so that the instance can later be completely restored in memory. The

dehydration of orchestration instances enables the orchestration engine to have more "in-flight"

instances than the physical resources of the computer running BizTalk Server would normally

53

ESPRIT 2011/2012

allow. Dehydration is automatically controlled by the orchestration engine; however, you can

control the dehydration threshold by changing specific BizTalk Server configuration properties.

Rehydration

Rehydration is the reverse of dehydration. It is the process of de-serializing the last running state of

an orchestration from the database or restoring the saved state of an orchestration instance from

disk back to memory. The orchestration engine is triggered to rehydrate an orchestration instance

when it either receives a message or when a time-out expires. It then loads the saved orchestration

instance into memory, restores its state, and runs it from the point where it left off.

An orchestration can be configured to run on more than one server. After an orchestration instance

has been dehydrated, it can be rehydrated on any of these servers. If one server goes down, the

engine continues to run the orchestration on a different server, continuing from its previous state.

The engine also takes advantage of this feature to implement load balancing across servers.

Calling External Assemblies

Through the course of a business process, there are times when the execution requires the

functionality of another .NET application or a functionality that is better developed in a different

common runtime language, such as C#. BizTalk orchestrations can pass parameters to external

applications through method calls, and subsequently integrate the functionality of external

applications into the BizTalk process.

Service Integration Scenarios

WCF and Web services are used to expose the functionality of a system or application to other

applications and are, by far, the most implemented mechanism for service enablement. BizTalk

Server fully supports existing WCF and Web service standards. This support enables developers to

both consume external services as part of a business process and publish a business process as

service that can be consumed by external applications.

If you require a specific business process to be accessible via the Internet to customers, trading

partners, or other applications, you can publish an orchestration as a WCF service. You do this by

running the BizTalk WCF Services Publishing Wizard. The wizard creates a WCF-based ASP.NET

application that runs within Internet Information Services (IIS).

Some examples of publishing an orchestration as a service include:

Airlines publish fare information online as a service. A travel Web site can call multiple airlines'

services to determine the current price for tickets from multiple airlines.

A shipping company exposes its business processes as online services. Online retailers can call the

shipper’s services to calculate shipping costs and display tracking information about the shipment to

their customers.

54

ESPRIT 2011/2012

Some common integration scenarios for integrating services into a business processes include:

Determining shipping costs from external shippers for a product

Calculating tax for an item depending on the country from which the item is being purchased

Obtaining a credit report or credit score from a third-party company when processing a loan

Accepting or denying a credit card for an online purchase

BizTalk Server enables you to call services from within an orchestration and through messaging

send ports. In addition, you can generate industry-standard Web services and custom WCF services

by publishing existing orchestrations or schemas, simplifying typically complex integration

scenarios.

BizTalk Service Integration Capabilities

In addition to the WCF adapters, BizTalk Server also provides the following support for integrating

with WCF services:

Consuming WCF services. . You can use the BizTalk WCF Service Consuming Wizard to generate

BizTalk artifacts, such as BizTalk orchestrations and types, which consume a WCF service based on

the metadata document of the WCF service.

Publishing orchestrations as WCF services. Using the WCF Publishing Wizard you can publish

BizTalk orchestrations as WCF services. Publishing an orchestration as a WCF service exposes the

functionality of the business process to external services such as trading partners or customers. Using

metadata from orchestration port types and schema types, the wizard automatically creates a WCF-

based ASP.NET application which acts as a WCF service façade for the BizTalk orchestration.

Publishing a schema as a WCF service. Publishing an orchestration as a WCF service binds the

message received through the service to the published orchestration. However, publishing a schema

as a WCF service provides a simple mechanism to submit messages to the MessageBox database.

Once in the MessageBox, the message can be routed to any number of subscribers for processing.

Publishing receive location metadata as WSDL.

BizTalk Server continues to support integration with ASMX Web services in the following ways:

Consuming WCF services. . Similar to consuming a WCF service, BizTalk orchestrations can call

external ASMX services.

Publishing orchestrations as WCF services. Similar to publishing an orchestration as a WCF service,

you can expose your business processes as ASMX services.

Publishing a schema as a WCF service. Similar to publishing a schema as a WCF service, schemas

can be published as ASMX services, to expose the message to external services.

BizTalk Orchestration in SOA Designs

A key principle of SOA is workflow or business process automation, which happens to be a major

strength of BizTalk Server. Service aggregation is one of the most common SOA patterns that

people use BizTalk Server to implement. Take a travel Web site for example; a travel Web site

55

ESPRIT 2011/2012

does not have a single database containing all the ticketing information for all the airlines in the

world. Instead each participating airline exposes its fare information by using a Web service. The

travel site executes the user's query against each airline's service and returns an aggregated set of

results.

APPENDIX B: Biztalk Configuration

1. Creating physical reception port

Step 1:

56

ESPRIT 2011/2012

Figure B: Add new reception port

Step 2:

57

ESPRIT 2011/2012

Figure C: Configure reception port location

Step 3:

Figure D: specify web service location

2. Creating physical sent port

58

ESPRIT 2011/2012

Step 1 :

Figure E : Add new sent port

Step 2 :

Figure F : Set sent port proprieties

59

ESPRIT 2011/2012

Step 3 :

Figure G: Define SQL binding proprieties

Step 4 :

Figure H: Set input and output mapping

60

ESPRIT 2011/2012

3. Binding orchestrations

Figure I: Binding orchestration

61

ESPRIT 2011/2012

Webliography:[1]: http://www.dotnet-france.com/

[2]: http://en.wikipedia.org

[3]: http://www.jot.fm

[4]: http://www.tutorials-expert.com

[5]: http://weblogs.asp.net

[6]: msdn.microsoft.com

[7]: https://docs.google.com

[8]: http://www1.ap.dell.com

Bibliography: 1) Foundation of Biztalk Server 2006

2) Pro Mapping in Biztalk Server 2009

62

ESPRIT 2011/2012

63

1