End Of Year Project

Design And Implementation Of An Examination Management Application

For ESPRIT

Elaborated by :
Chalghoumi Najoua Bakir Mohamed El Khamed

Supervised by :
Ms Khiari syrines

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 universitys 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. 2.
PROBLEMATIC .............................................................................................................................. 2

SOLUTION .................................................................................................................................... 3

CONCLUSION ....................................................................................................................................... 3 CHAPTER 2 : STATE OF THE ART ........................................................................................... 4 INTRODUCTION .................................................................................................................................... 4 1. 2. a. b. c. d. 3.

KEY CONCEPTS ............................................................................................................................. 4 STUDY OF THE EXISTING ............................................................................................................ 11

Study of the current situation ............................................................................................ 11 Problematic ....................................................................................................................... 12 Current situation in jendouba university ........................................................................... 13 Tools on the market ........................................................................................................... 13 METHODOLOGIE AN CYCLE OF DEVLOPMENT ........................................................................... 16

CONCLUSION ..................................................................................................................................... 19 CHAPTER 3 :ANALYSIS AND SPECIFICATION OF REQUIREMENTS .......................... 20 INTRODUCTION .................................................................................................................................. 20 1. 2. 3. 4. FUNCTIONAL REQUIREMENTS.................................................................................................... 20
NON-FUNCTIONAL REQUIREMENTS ........................................................................................... 21

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

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

CONCLUSION ..................................................................................................................................... 25 CHAPTER 4 : DESIGN................................................................................................................. 26 INTRODUCTION .................................................................................................................................. 26 1.

CONCEPTUAL CHOICES

.............................................................................................................. 26

Choices of architecture ..................................................................................................... 26 2. 3. a. b. CLASS DIAGRAM ........................................................................................................................ 28

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

Sequence diagram ............................................................................................................. 30 Activity diagram ................................................................................................................ 32

c.

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

CONCLUSION ..................................................................................................................................... 35 CHAPTER 5: IMPLEMENTATION ........................................................................................... 36 INTRODUCTION .................................................................................................................................. 36 1. a. b. 2. a. b. c. DEVLOPMENT ENVIRONMENT ................................................................................................... 36 Hardware environment...................................................................................................... 36 Software environment ........................................................................................................ 36 IMPLEMENTATION ..................................................................................................................... 39 Results in biztalk testing .................................................................................................... 39 Site Map............................................................................................................................. 40 Web pages ......................................................................................................................... 41

CONCLUSION ..................................................................................................................................... 44 GENARAL CONCLUSION .......................................................................................................... 45 APPENDIX: .................................................................................................................................... 46 WEBOGRAPHIE: ......................................................................................................................... 56 BIBLIOGRAPHIE :....................................................................................................................... 56

List of figures
FIGURE 1 : SPAGHETIS ARCHITECTURES ........................................................................................... 5 FIGURE 2 : THE BPM FUNCTIONALITIES ............................................................................................. 6 FIGURE 3 : THE ENTREPRISE SERVICE BUS ....................................................................................... 7 FIGURE 4 : BIZTALK COMPONENTS ...................................................................................................... 9 FIGURE 5 :BIZTALK ENGINE COMPONENTS .................................................................................... 11 FIGURE 6 :EXAMINATION SYSTEM OF JENDOUBA UNIVERSITY .............................................. 13 FIGURE 7 :ORGANET MANAGEMENT SYSTEM ................................................................................ 14 FIGURE 8 : EDUSOFT EXAMINATION MANAGEMENT ................................................................... 15 FIGURE 9 : SCRUM METHODOLOGY ................................................................................................... 17 FIGURE 10 : THE WORK MADE DURING EACH SRINT ................................................................... 19 FIGURE 11 : USE CASE DIAGRAM ......................................................................................................... 22 FIGURE 12 : THE APPLICATION ARCHITECTURE........................................................................... 27 FIGURE 13 :CLASS DIAGRAM ................................................................................................................ 28 FIGURE 14 : SEQUENCE DIAGRAM VIEW SCHEDULE ................................................................ 30 FIGURE 15 : SEQUENCE DIAGRAM ADD TEST .............................................................................. 30 FIGURE 16 : SEQUENCE DIAGRAM UPDATE CLASSROOM....................................................... 31 FIGURE 17 : ACTIVITY DIAGRAM AFFECT SUPERVISOR ......................................................... 32 FIGURE 18 : ACTIVITY DIAGRAM DISAFFECT CLASSROOM .................................................. 33 FIGURE 19 : ACTIVITY DIAGRAM VIEW SCHEDULE .................................................................. 34 FIGURE 20 : STATE MACHINE DIAGRAM CLASS CLASSROOM .............................................. 35 FIGURE 21 : SELECT SUPERVISOR ORCHESTRATION................................................................... 39 FIGURE 22 :INSERT SUPERVISOR ORCHESTRATION .................................................................... 40 FIGURE 23 :SITE MAP ............................................................................................................................... 40 FIGURE 24 :HOME PAGE.......................................................................................................................... 41 FIGURE 25 : ADMINISTRATOR UTHENTICATION ........................................................................... 42 FIGURE 26 : CLASSROOMS MNAGEMENT ......................................................................................... 43 FIGURE 27 : SUPERVISORS MANAGEMENT ...................................................................................... 43

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 preexamination 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 examinations 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.

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 examinations 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 students 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. Need of Several People:

ESPRIT
costs. Errors: There is chance for more manual errors.

2011/2012

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

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.

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-topoint interfaces were added to solve the integration needs. As people use the systems, they find that they need information from other systems, and point-topoint integration emerges. There are many types of point-to-point integrations: ETL (extract, transform Load), which is a DB-to-DB relationship; online and filebased, 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 Expensive systems regarding multiple implementations We need interfaces for each application Redundant interconnections (point to point integration)

ESPRIT
Great complexity Hard to maintain

2011/2012

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

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

ESPRIT

2011/2012

scenarios. As with other technologies, using this approach makes sense only when its 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 formsbased client-side front ends. In essence, ESB does for distributed 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

ESPRIT

2011/2012

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:
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.

ESPRIT

2011/2012

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 businessoriented 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 Execution Language (WSBPEL). Biztalk combine different systems into an

ESPRIT
effective business processes; include a range The figure below illustrates the products major components:

2011/2012
of technologies.

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 engines messaging components, orchestrations implement the logic that drives all or part of a business process.

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.

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.

11

ESPRIT

2011/2012

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 examinations subject have to take their examination in a single date. A group mustnt 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 mustnt be affected to two groups at the same time. A supervisor mustnt supervise nor his subject neither his group. A supervisor mustnt supervise twice per day.

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.

12

ESPRIT

2011/2012

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.

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:

13

ESPRIT
ORGANET

2011/2012

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.

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 examinations 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.

14

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.

15

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

16

ESPRIT
backlog and burn down chart accordingly.

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

17

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:

18

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.

19

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 whats 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

20

ESPRIT
2. Non-functional requirements

2011/2012

In this part we are interested to the second category of our systems 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 examinations timetables in order to fulfill the main projects goal: well Examination management.

21

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

2011/2012

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:

22

ESPRIT
Manage accounts Use cases name Main actor Goal in context Assumptions (precondition) Successful end condition Fall end conditions Scenario (Main path) Manage accounts Administrator

2011/2012

The management of accounts by the administrator The administrator must have an account to access the application. The administrator must authenticate. Administrator successfully authenticates and he is re-directed to manage accounts. Administrator is not able to authenticate. 1. Log in as an administrator 2. The system verify information 3. The system display the administrative page 4. The user select the menu option Manage accounts 5. The user select the wanted operation (add / remove /update) 6. The system asks for confirmation 7. The user confirms 8. The update is done by the system

Manage Exams date Use cases name Main actor Goal in context Assumptions (precondition) Successful end condition Fall end conditions Scenario (Main path ) Manage exams date Administrator Schedule exams The user must have an account to access the application. The user must authenticate as an administrator User successfully authenticate and hi sis re-directed to User is not able to authenticate 1. Log in as an administrator 2. The system verify information 3. The system display the administrative page 4. The user select the menu option Manage exams schedule 5. The user enter examinations and their date 6. The system asks for confirmation 7. User confirms 8. Examinations are scheduled

23

ESPRIT
Manage classes Use cases name Main actor Goal in context Assumptions (precondition) Successful end condition Fall end conditions Scenario (Main path) Manage classes Administrator Affect a classroom to each group The user has an account

2011/2012

User successfully authenticate and hi sis re-directed to User is not able to authenticate 1. Log in as an administrator 2. The system verify information 3. The system display the administrative page 4. The user select the menu option Manage classes 5. The user affect each group to a classroom 6. The system asks for confirmation 7. User confirms 8. All groups are affected to classrooms

Manage supervisors Use cases name Main actor Goal in context Assumptions (precondition) Successful end condition Fall end conditions Scenario (main path) Manage supervisors Administrator Affect a supervisor to each group The user has an account User successfully authenticate and hi sis re-directed to User is not able to authenticate 1. Log in as an administrator 2. The system verify information 3. The system display the administrative page 4. The user select the menu option Manage supervisors 5. The user affect each supervisor to a classroom 6. The system asks for confirmation 7. User confirms 8. All supervisors are affected to classrooms

24

ESPRIT
Conclusion

2011/2012

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.

25

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 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)

26

ESPRIT

2011/2012

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) 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:

27

ESPRIT

2011/2012

Figure 12: The applications architecture

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.

28

ESPRIT

2011/2012

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. 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)

29

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

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:

30

ESPRIT
Examination Test Supervisor Classroom Class Group Block Level User Administrator Sance

2011/2012

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.

View Schedule:

31

ESPRIT

2011/2012

Figure 14: Sequence diagram view schedule

Add test:

Figure 15: Sequence diagram add test

Update classroom:

32

ESPRIT

2011/2012

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.

33

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 the administrator put new information. At that time, these new data are stored in the data base.

34

ESPRIT
Disaffect classroom:

2011/2012

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.

view schedules

35

ESPRIT

2011/2012

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 classrooms addition, the state of this class can show error message or sit can be added.

36

ESPRIT

2011/2012

Figure 20: State machine diagram classroom class

Conclusion In this chapter, we detailed the simulators 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.

37

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

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.

38

ESPRIT

2011/2012

Description:

PowerDesigner is

a collaborative enterprise

modelling tool

produced by Sybase. PowerDesigner runs under Microsoft Windows as through a native application, and runs under Eclipse

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.

Description:

BizTalk Server 2010 is Microsofts Integration and connectivity server solution. It provides a solution that allows organizations to more easily connect disparate systems. Including over 25 multiplatform 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.

39

ESPRIT

2011/2012

Description: Visual Studio 2010 from is an integrated It user development is used to environment (IDE) along Microsoft.

develop console and graphical with Windows

interface applications sites, web

Forms applications, web

applications, and web services in both native code together with managed code for all platforms supported by Microsoft Windows, Windows Framework, .NET Silverlight. This tool Mobile, Windows Compact supports different CE, .NET programming Framework and Microsoft

languages by means of language services, which allow the code editor and debugger to support (to varying degrees) nearly any programming language, provided a languagespecific service exists.

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

40

ESPRIT
2. Implementation

2011/2012

a. results in Biztalk orchestration These are results in BizTalk orchestration; all tests were conducted using .asmx technology stack:

Figure 21: Select supervisor orchestration

41

ESPRIT

2011/2012

Figure 22: Insert supervisor orchestration

b. site map The following figure represents the map of our site:

Figure 23: Site map

42

ESPRIT
c. web pages

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

43

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.

44

ESPRIT
Classroom management

2011/2012

Figure 26: Classroom management Supervisors management

Figure 27: Supervisors management

45

ESPRIT

2011/2012

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

46

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 examinations pre-activities and nowadays we need such a tool

which deals also with examinations 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.

47

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 you to create well-documented orchestrations that have fewer crisscrossing connectors, making your orchestrations easier to read.

48

ESPRIT

2011/2012

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.

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:

49

ESPRIT

2011/2012

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 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

50

ESPRIT

2011/2012

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 shippers services to calculate shipping costs and display tracking information about the shipment to their customers. 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

51

ESPRIT

2011/2012

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 WCFbased ASP.NET application which acts as a WCF service faade 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 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.

52

ESPRIT

2011/2012

APPENDIX B: Biztalk Configuration 1. Creating physical reception port

Step 1:

Figure B: Add new reception port

53

ESPRIT
Step 2:

2011/2012

Figure C: Configure reception port location Step 3:

Figure D: specify web service location

54

ESPRIT
2. Creating physical sent port
Step 1 :

2011/2012

Figure E : Add new sent port Step 2 :

Figure F : Set sent port proprieties

55

ESPRIT
Step 3 :

2011/2012

Figure G: Define SQL binding proprieties Step 4 :

Figure H: Set input and output mapping

56

ESPRIT

2011/2012

3. Binding orchestrations

Figure I: Binding orchestration

57

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

58