RECONSTRUCTION DU SITE INTRANET DE GESTION DES SALLES DE REUNION

CNAM 2005-2006 NFE 210 Ingnierie des Systmes d'Information

Frdric Petitdemange

       

    

SOMMAIRE
 #            !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! " $  % & '   (    ) *    ' +  ' !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! , # ! - ( . ' &     ' & & ( //' &  '  %     0000000000000000000000000000000000000000000000000000000000000000000000000000 1  0202  0 2 0 # !# # !< # !@ # !B # !" < 3 4
 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 5 3 4
 6 6 4 7 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 2  - 89 &    :  '  ' / 8( ; ; /  (    0000000000000000000000000000000000000000000000000000000000000000000000000000000 2  - ' ; %  = >   '  '   ( ? ( / 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 2 - ' &    ? ' // ' & A        ( /  % &  ' = (   % ' & 00000000000000000000000000000000000000000000000000000000000 2 - ' & C ' &   &    A        ' / & 0000000000000000000000000000000000000000000000000000000000000000000000000000000 2 - ' & &  (   (    ' / 8'    ' ;  & ' 00000000000000000000000000000000000000000000000000000000000000000000000000000000 2

D '    &        !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!  B < ! - 8(   9  '     ' & E &  > = ' 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 2   0202 < !# 3 4 F G 00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 2  3 H I J 7
K
L 
M  00000000000000000000000000000000000000000000 2 N  0 2 0 - 8(   9  '     '  ' & ; ( . ' & O ' C 000000000000000000000000000000000000000000000000000000000000000000000000000000 2 N  0 0 2 < !< 3 
P Q
 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 2 N 3 6 
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 2 1  0 0 - ( C ( & '  '     % ' & 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 25  0 0 2  0 0  0 0  0 0 < !@ < !B < !" < !X < !, < !Y < ! Z < !  3  
 G 

 000000000000000000000000000000000000000000000000000000 2 5 3  G 

 0000000000000000000000000000000000000000000000000000000000000000000000000000000000  R  I
S T H U 3 00000000000000000000000000000000000000000000000000000000000000000000000 5  
7   0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0  2

V  ( /E & '      ' W     ' 000000000000000000000000000000000000000000000000000000000000000000000000000000000000000  2 D '    &         ' &  > . / ' &  ' A        ' = '   0000000000000000000000000000000000000000000000000000  V  ( /E & '    ' & .    / & % 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000   V  ( /E & '  ' / ( & %     % 000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000   - ' & C ' &   & A        ' / &   (  + 0000000000000000000000000000000000000000000000000000000000000000000000000  - ' & C ' &   &    A        ' / &   (  + 00000000000000000000000000000000000000000000000000000000000000000  - ' & C ' &   &   (  +       ? '   0000000000000000000000000000000000000000000000000000000000000000000000000  V  ( /E & '  ' / (  '    &        0000000000000000000000000000000000000000000000000000000000000000000000000000000  

@ B

[  ( /  %  ' / 8( ; ; /  (    !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! < " - ' & % ?  /     &  %  ' & & (  ' & &  '  ' /(  '    &        !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! < Y B ! - 8(   9  '     ' & E &  > = ' 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000  5 B !# B !< - 8(   9  '     '  ' & ; ( . ' & O ' C 000000000000000000000000000000000000000000000000000000000000000000000000000000  5 \ ( & '  '     % ' & '   ;  = & (    0000000000000000000000000000000000000000000000000000000000000000000000000   0 0 2  0 0 B !@ 3 H K L M 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000  3  G 

 0000000000000000000000000000000000000000000000000000000000000000000000000000000000 

- '    ' &     ' 000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 2 _ & ' '  A   = ' ` * W W 00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000  \ ( & '  '     % ' & '   ;  = & (    0000000000000000000000000000000000000000000000000000000000000000000000000  *   A   =  %   &  ' 00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000     '  A (  ' & 00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000  *   ' &     ' a b _ - 000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000  - ( . ' &     ' &  AA %  '   & / (  . ( . ' &   / & % & 0000000000000000000000000000000000000000000000000000000000  c 8(    ' & C    ' & ;  (  :  ' &   O ' C 0000000000000000000000000000000000000000000000000000000000000000000000 

"

- ' & C    ' & ;  (  :  ' &    % ? ' /  ; ; ' = '   ] ^ \ !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! @ # " ! " !# " !< " !@ " !B " !" " !X

       

    

X ,

*    /  &   !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! @ @ V   ' + ' !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! @ B , ! - &   .   A  9 '  d c /  .  !( & ; d ! 00000000000000000000000000000000000000000000000000000000000000000000000000  , !# , !< , !@ , !B - &   .   A  9 '  d -  .  # !( & ; d ! 0000000000000000000000000000000000000000000000000000000000000000000000000 N - &   .   A  9 '  d / .   9 '  e !( & ; d ! 0000000000000000000000000000000000000000000000000000000000000000000 1 - &   .   A  9 '  d *  A A ' ' !( & ; d ! 00000000000000000000000000000000000000000000000000000000000000000000000000 5 - &   .   A  9 '  f d  ' &g A   = g & ( ? ' !( & ; d ! 00000000000000000000000000000000000000000000000000000000000  

\ C /  !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! B @

       

    

SOMAIRE DES ILLUSRATIONS

h  2 i j 6
 000000000000000000000000000000000000000000000000000000000000000000000000000000000000 N h   i j 6
 S   0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0  h   i k  G  
6

S   0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0  0000000000000000000000000 2 

Figure 4 - Etat de la rservation des salles pour 0la journe en cours. 000000000000000000000000000000000000000000000000000000000000 2 2 Figure 5 - Formulaire de rservation d'une salle 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 2 2 Figure 6 - Formulaire de rservation rcurrente - 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 2  Figure 7 - Formulaire de rservation rcurrente - 2 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 2  Figure 8 - Formulaire de rservation rcurrente - 3 00000000000000000000000000000000000000 2  Figure 9 - Formulaire de vrification des approvisionnements 000000000000000000000000000000000000000000000000000000000000 2  Figure 10 - Structure des fichiers de l'application 00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 2 5 Figure 11 - plan du site intranet0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0  1 Figure 12 - Le MLD reconstruit 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0  5 Figure 13 - Le MCD reconstruit 0000000000000000000000000000000000000000000000000000000000  Figure 14 - Nouvelle structure des fichiers source 0000000000000000000000000000000000000000000000 2 Figure 15 - Le nouveau Modle Conceptuel de Donnes

SOMAIRE DES TABLES

Table 1 - Description des informations physiques des tables 0000000000000000000000000000000000000000000000000000000000000 2 Table 2 - Description de la table "Administrator" 0000000000000000000000000000000000000000000000000000000000000000000 2 Table 3 - Description de la table "Recurring" 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0   Table 4 - Description de la table "Reservation" 000000000000000000000000000000000000000000000000000000000000000000000000  Table 5 - Description de la table "Rooms" 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 N Table 6 - Qualit des donnes 0000000000000000000000000000000  Table 7 - Les facteurs de fonctionnement de la base de donnes 000000000000000000000000000000000000000000000  Table 8 - Les facteurs d'volution de la base de donnes 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0   Table 9 - Les facteurs d'adaptation de la base de donnes 00000000000000  Table 10 - Les facteurs de Deutsch & Willis appliqu la base de donnes 000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000  Table 11 - Qualit de la base 00000000000000 1 Table 12 - Les facteurs de Deutsch & Willis appliqu la base de donnes 00000000000000000000000000000000000000000000000000000000 1 Table 13 - Les facteurs d'volution du code source 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0  1 Table 14 - Les facteurs d'adaptation du code source 000000000000000000000000000000000000000000000000000000000000000000000000000000000000 1 Table 15 - Qualit du code source 000000000000000000000000000000000000000000000000000000000000000000000000000 1 Table 16 - Qualit de la structure fichier 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000 5 Table 17 - Qualit de l'application
000000000000000000000000000000000000000 

       

    

1 Introduction
Le projet que je souhaite partager avec vous est celui qui m'a t offert de faire sur une petite application de type web dont la fonction principale est la gestion des salles de runion. Cette application est journalirement utilise soit par le personnel de la rception pour effectuer les rservations ncessaire soit par l'ensemble des membres de l'entreprise pour visualiser les disponibilits ou l'quipement des salles de runion. C'est donc une application la fois simple dans sa dfinition et importante du point de vue fonctionnel pour une entreprise effectuant beaucoup de runion avec ces clients, prestataires ou personnels internes. Pour effectuer notre travail de reconstruction de notre application, nous allons dans un premier temps effectuer une rtro conception de notre site en effectuant un "Design Recovery" afin de remonter au niveau d'abstraction le plus lev via une approche "Botton-up". Nous effectuerons par la mme occasion une "Redocumentation" de tout ou partie de la documentation manquante la bonne comprhension et la poursuite de la reconstruction du site. Enfin, nous approcherons la phase de "Restructuring" qui nous permettra d'effectuer une modification de la reprsentation actuelle des donnes, de la structure de l'application ou du code en une reprsentation plus proches du rel ou des bonnes pratiques de dveloppement. Mais aussi du "Refactoring" qui consiste simplifier, optimiser et documenter un code source. Ceci afin de prparer la phase de "Forward Engineering", phase classique et normale de conception vers l'avant d'une application (oppos aux phases de "Reverse Engineering" dans le sens du dveloppement).

l m n o p q r s t u v w x y z { x |} ~ x w u v z~ w zu v

Lors de la reconstruction de cette application, une question va trs vite surgir propos de l'approche choisie, l'approche "Botton-Up" versus "Top-Down". Dans un cadre dnu d'un intrt CNAMIEN pour l'laboration de ce projet, j'aurais de trs vite chang d'approche pour une approche "Top-Down". J'aurais repris par les fonctionnalits attendu en crivant le cahier des charges dans une phase normale de conception avanc de l'application et inclus une recherche sur l'tagre d'un logiciel existant. L'approche "Botton-Up" a t garde pour mettre en avant au travers de ce document les problmatiques de reconstruction d'un site web a travers une mthodologie ou manire de faire et en mettant en avant les problmatiques de qualit de l'application.

       

   N 

Le concept de la qualit est bas sur le contrle puis l'amlioration de cette qualit et enfin son management comme prsent par la figure suivante.

l m n o p q s t u v w x y z { x |} } |z

Ces deux concepts peuvent tre fusionn et toff pour donner un tableau crois des diffrents concepts de la reconstruction et de la qualit. Ce tableau pouvant servir dans ces deux dimensions pour faire d'un concept (Design recovery, refacturing ou d'autre) un lment permettant de faire de la reconstruction et de la qualit.

l mn o p q s } |x } w ~ u  { x  w u v w x y z  { x ~ x w u v z~ w zu v x z { x } |z

C'est cette prsentation des donnes qui sera suivit tout au long de la prsentation de la reconstruction de notre application. Nous allons dans un premier temps prsenter l'application dans son contexte, puis prsenter la reconstruction effectue sur les donnes, son SGBD, la structure fichier de l'application, le code source et le design. En troisime phase, je prsenterai la phase de "restructuring" ou phase reconstructionvolution du modle, de la structure ou du code. Suivra une notation de la qualit de l'application, une prsentation de quelques bonnes pratiques du Web et je finirai par la conclusion.

       

    

2 Prsentation Contexte
L'application a t conu 6 ans plus tt dans un contexte trs fort de webisation outrance ou le client lger t le mode choisi par tous pour apporter les fonctionnalits demand par les clients/utilisateurs. A cette poque, le DSI et/ou le responsable des moyens gnraux en place ont pour des raisons non connu prfr de travailler avec un dveloppeur tranger (Pays-Bas). Le responsable des moyens gnraux n'avait aucune connaissance dans le dveloppement WEB et souhait fortement travailler avec ce dveloppeur tranger, le DSI qui avait une forte connaissance de ces projets puisque lui-mme chef de projet WEB en SSII n'avait par contre que peut de temps y consacrer. Les besoins ont t succinctement formaliss via email, cet email n'tant plus disponible ce jour. Les recherches d'informations sur cette application se sont soldes par: plus de dveloppeur il a totalement disparu de la scne et n'est plus joignable. aucune documentation (dfinition des besoins, cahier des charges, description fonctionnel, etc.), mme obsolte il n'y a rien, voir mme il semble qu'il n'y a jamais rien eu. perte de mmoire complet de la gestion de ce projet. Les seuls lments tangible restant notre disposition sont les utilisateurs, le responsable des moyens gnraux qui ne se rappelle plus de tout ce qui c'est dcid sur ce projet mais qui souhaiterait le voir voluer, et bien sure l'application elle-mme. Pourtant, quelques points positifs viennent s'ajouter ce descriptif. Le premier est que l'application fonctionne sur un serveur WEB intgrant un gestionnaire de base de donnes dont l'application fait usage (gage me semble t'il d'un minimum de srieux et d'intrt pour ce projet). Le second point positif est que l'application n'a jamais subi de problme technique hormis des problmes de performance lors de mise en charge du gestionnaire de base de donnes par des bases issue de nos propres clients pour y faire des d'analyses (gage me semble t'il du srieux du dveloppement et du modle conceptuelle de donnes utilis). Le troisime et non des moindre, est que les utilisateurs sont content de leur application.

2.1 La gestion des salles de runion

L'application web de gestion des salles de runion est accessible par deux types de population. Les premiers peuvent effectuer les rservations modifier ces rservations supprimer ces rservations grer le rapprovisionnement des salles
           1 

Et les seconds ne font que visualiser l'ensemble des informations de rservation. 2.1.1 Le suivit des salles Le suivit des salles de runion consiste pour les membres de la rception de grer les salles, le besoins de ceux qui en on besoins en fonction des quipements install (systme de vidoconfrence, projecteur, lecteur DVD, systme de confrence tlphonique, etc.), et le rapprovisionnement de ces salles en boisson, caf et autres services. Les membres de la rception sont les seules pouvoir effectuer la cration, modification ou annulation de rservation des salles de runion. L'interview m'apprendra aussi qu'une rservation peut-tre rcurrente dans le temps et que l'interface graphique t volontairement choisi pour une utilisation la plus simple possible. Un intrimaire devant pouvoir effectuer une rservation simplement, rapidement et sans connaissance pralable. L'application a les interfaces graphiques suivant pour effectuer toute la gestion des salles de runion.

       

   5 

L'interface principale prsente la rservation des salles pour la journe en cours comme le prsente la Figure 4 - Etat de la rservation des salles pour la journe en cours.

Figure 4 - Etat de la rservation des salles pour la journe en cours.

       

   2 

Le formulaire suivant prsente l'interface de rservation d'une salle.

Figure 5 - Formulaire de rservation d'une salle

Les formulaires suivants prsents la manire d'effectuer une rservation rcurrente. Le premier permet de slectionner la cration ou la suppression d'une rservation rcurrente.

Figure 6 - Formulaire de rservation rcurrente - 1

       

   2 2 

L'tape suivante consiste dans le choix de la salle de runion et dans celui de la rcurrence de cette runion, soit : journalire hebdomadaire mensuelle

Figure 7 - Formulaire de rservation rcurrente - 2

Enfin, la prise de rservation rcurrente se termine par la slection d'information horaire et de date.

Figure 8 - Formulaire de rservation rcurrente - 3

2.1.2 Le suivit des approvisionnements Le suivit des rapprovisionnements consiste pour une personne de la rception vrifier que les besoins exprims par les utilisateurs lors de la rservation sont bien pris en compte lors de la prparation des salles et de dlivrer ce service en portant la bouteille d'eau, le caf ou les plateaux repas commands. Pour cela, elle on besoins de vrifier le jour d'avant les besoins pour effectuer les commandes ncessaire, le matin mme pour organiser l'installation dans les

       

   2 

salles des commandes et au cours de la journe pour s'assurer d'aucun oublie. A noter que notre application effectue un suivit des approvisionnements mais en aucun cas la commande de ceux-ci. Le formulaire suivant prsente le formulaire de vrification de l'approvisionnement des salles.

Figure 9 - Formulaire de vrification des approvisionnements

2.2 L'historique de l'application

L'historique de l'application est assez simple dcrire Il n'y en a pas ou trs peu. La date de mise en service est au alentour de l'anne 2000, sans certitude. Personne ne se rappel non plus du nom du dveloppeur. Il semble qu'il n'y a jamais eu de documentation que ce soit sous la forme d'un cahier des charges ou d'une documentation de fonctionnement. Il n'y a rien si ce n'est l'application elle-mme, les utilisateurs de ce systme et le commanditaire ou "Matre d'Ouvrage" de l'application.

       

   2 

2.3 Le primtre de travail

Le primtre de travail n'incluse pas les serveurs proprement dit (Web ou SQL) ni tout autre lment de l'infrastructure physique de l'entreprise. On ne cherchera pas modifier le nom de l'application (impact DNS,..) ni la localisation de l'application (impact server web,). Nous ne travaillons que sur l'application et uniquement sur elle.

2.4 Les nouvelles fonctionnalits demandes

Les nouvelles fonctionnalits demandes sont : une gestion des actions effectues, pour savoir qui fait quoi l'administration (cration/suppression) des salles de runion Il n'y a pas d'autre nouvelle fonctionnalit puisque l'application donne toute satisfaction et que les utilisateurs de ce systme ne s'en plaignent pas.

2.5 Les besoins non fonctionnels

Les besoins non fonctionnels cit par le MOA sont : simplicit d'utilisation fiable rapide Afin de ne pas rajouter aux stresses quotidien des rceptionnistes utilisateurs principaux de ce systme.

2.6 Les standard de l'entreprise

L'entreprise fonctionne dans un grand groupe mondial prsent dans une soixantaine de bureau dans le monde soit cinquante pays diffrents. L'informatique est structure autour de trois grands ples infrastructure, application et service. L'ensemble est rgi par des standards de fonctionnement qui pour notre exemple se rsume au tout Microsoft Serveur Web, serveur de base de donnes, operating systme Microsoft, le tout suivit par des systmes de monitoring afin de mesur les taux de disponibilits et par une quipe charg de suivre au quotidien la maintenance hardware et software (patch de scurit) de ces serveurs.

       

   2 

3 Reconstruction
La reconstruction du systme d'information se fera soit de manire squentiel soit de manire plus itrative lorsque la recherche des informations seront plus complexe. Pour effectuer notre travail de reconstruction de notre application, nous allons dans un premier temps effectuer une rtro conception de notre site en effectuant un "Design Recovery". Il s'agit de remonter au niveau d'abstraction le plus lev par une approche "Botton-up". Nous partons des lments de base qui sont mis en notre possession (base de donnes, schma de la base, code source,..) pour reconstruire ou recrer les documents de base permettant une comprhension sans quivoque du fonctionnement de l'application comme le modle conceptuel de donnes, la structure de l'application ou le cahier des charges fonctionnels de l'application. Nous effectuerons par la mme occasion une "Redocumentation" de tout ou partie de la documentation manquante la bonne comprhension et la poursuite de la reconstruction du site. Ce sont entre autre les documents dcrivant les lments prcdents la bonne comprhension de l'application. Enfin, nous approcherons la phase de "Restructuring" qui nous permettra d'effectuer les modifications de la reprsentation actuelle des donnes, de la structure de l'application ou du code source de l'application en une reprsentation plus proches du rel ou des bonnes pratiques de dveloppement. Ceci afin de prparer la phase de "Forward Engineering", phase classique et normale de conception vers l'avant d'une application (oppos aux phases de "Reverse Engineering" dans le sens du dveloppement) afin de prendre en compte les modifications demandes. Je commencerais par le plus simple et le plus visible, l'architecture du systme travers les lments cl (serveur Web, serveur de Base de Donnes,..). Puis la reconstruction de la structure des pages web de l'application. S'en suivra la reconstruction de la base de donnes, l'analyse du code, la recherche des rgles de fonctionnement, des rgles utilises pour le design et de la scurit. Enfin, je finirais par les besoins fonctionnels et non fonctionnels, les besoins non couvert et par une conclusion sur cette reconstruction. C'est une approche de type "Botton-up" ou l'on part de l'existant pour remonter vers le cahier des charges originel, vers le besoin exprim ou pas des utilisateurs.

3.1 L'architecture systme

3.1.1 Le serveur web C'est peut-tre la partie la plus simple du puzzle. Trs vite j'ai identifi le serveur web hbergeant l'application Je savais que l'application est une application locale, do exit les serveurs web des data-centers. Ce point a t confirm par une simple vrification DNS. Localement, il n'y a qu'un seul serveur, donc cela ne pouvais tre que lui. Un rapide coup d'il sur les applications supportes m'a confirm sur ce point.
           2  

3.1.2

Le Systme de Gestion de Base de Donnes Ayant trouv le serveur web hbergeant l'application, un rapide coup d'il ma permis de voir que ce serveur supportait aussi un moteur de SGBD de type SQL. J'ai alors vrifi dans les pages web source que c'tait bien un serveur MS SQL qui tait requt. A ma grande surprise, c'tait un moteur Microsoft de type MS Access 7.0. Le fichier "acces_base.inc" charg au dbut de plusieurs pages de l'application, pointait vers le fichier "RoomsParis.mdb", ne laissant aucun doute. Les pages crites en ASP dmontraient le besoins d'avoir des pages web dynamique. L'architecture de cette application est donc articule autour d'un serveur web IIS et d'un moteur de BD MS Access.

3.2 L'architecture des pages web

La reconstruction de l'architecture du site passe pas deux tapes. La premire consiste retrouver le chemin complet, au travers de toutes les pages, empruntes par l'application lors de son excution. Cela permet ainsi de retrouver les pages de tests ou non utilises. Le rsultat est un graphe connexe pouvant avoir plusieurs niveaux d'arborescence dont la particularit est d'avoir de nombreuses pages se connectant la page principale de l'application. Ce qui prsente une certaine circularit de la structure de l'application. La seconde consiste retrouver les fonctionnalits principales du site et de reconstruire la carte "map" du site au travers de ces grandes fonctionnalits. Ce sont vers ces pages que l'utilisateur du site sera redirig en fonction des besoins demands. 3.2.1 La structure des fichiers du site intranet Le principe utilis pour reconstruire la structure de l'application est la mise en place d'une arborescence ou une page pointe vers une autre page. Le but est d'tablir un graphe connexe (ce qui n'est pas toujours le cas) ou chaque pages est un nud du graphe, chaque liens vers une autre page est un arc du graphe. Chaque arc du graphe sera donc vu comme une nouvelle fonction possible ou une suite logique dans la mise en uvre de cette fonction. Si l'arbre n'est pas connexe, cela veut dire que des pages ne sont jamais adresses et sont donc inutiles l'application. Une particularit des structures web et de prsenter des arbres connexe circulaire (mais pas toujours) dont les

       

   2N 

dernires feuilles de l'arbre pointent vers la "home page" pour revenir au point de dpart. La premire page choisi est notre nud de dpart. A partir de ce nud, on dfini toutes les pages adresses par celle-ci crant un arc reliant notre nud principale au nud(s) secondaire(s). Chaque page point (nud de l'arborescence) devient une branche qu'il faudra parcourir. On itre ainsi chaque page adress afin de parcourir toutes les branches de l'arborescence. Une fois cela fait, il faut effectuer cette recherche sur toutes les autres pages non parcouru. Il se peut en effet que l'on n'ait pas commenc par le dbut ou qu'il y ait plusieurs commencements possibles. La premire page choisit fut celle propos par le serveur web et indiqu par le serveur DNS. J'ai donc commenc la construction de mon graphe partir de la page "Home.asp". L'itration des pages ASP fut rapide puisqu'il n'y avait que vingtquatre pages. La figure suivante prsente la structure des fichiers se trouvant dans le rpertoire racine de l'application.

Figure 10 - Structure des fichiers de l'application

Cette premire tape prsente la structure des fichiers utiliss par l'application.
           2 

Premier constat, la prsence d'un fichier non connect au graphe. A lors que le graphe doit tre connexe, Je dcouvre un fichier non connect. Cela m'indique qu'il ne sert pas l'application. Deuxime constat, la prsence de quatre possibilits pour ce connecter l'application. Cela dnote soit une tentative d'ajout de fonctionnalit, soit une tentative de maintenance. Les noms des quatre points de dpart me feront penser dans un premier temps une tentative d'ajout, mais l'utilisation je dcouvre un disfonctionnement majeur. S'agissait-il en faite d'une tentative d'ajout et de maintenance non rsolu jusqu' ces jours ? La tentative de modification est corrl par le faite que l'une des frames se nomme "Tool" est que justement cette application semble cruellement faire dfaut de page d'administration permettant par exemple de grer une salle de runion. Nous verrons plus loin la manire dont cela t fait lors de l'analyse de la base de donnes. La tentative de maintenance vient du faite que lorsque l'on se connecte la base, la premire page web charge la page ou s'effectue le login proprement dit et que celle-ci transmet l'ensemble des paramtres une autre page pour vrification. En fonction de quoi cette dite page retour le rsultat la toute premire page pour lui signifi une validation ou pas. L'un des arguments transmit outre la validation ou pas du login et le non de la frame L est l'erreur de programmation. Un mauvais nom de frame est transmit, l'application ne trouve pas et demande le chargement d'un second browser internet, mme s'il y a validation du login On se retrouve donc dans un fonctionnement normale de l'application avec deux pages web ouverte, l'une rest sur l'interface de login l'autre sur la page principale du site ouvert aprs login. A premire vue les pages terminales du graphe semblent retourner vers la page principale "home" du site. Nous verront plus loin qu'il n'en tait rien en faite, obligeant les utilisateurs faire un "back" sur le browser internet pour revenir la "home page" du site. Il n'y a pas circularit de notre graphe connexe ou les pages d'extrmits de notre graphe ne pointent pas vers notre page de dpart.

Mon graphe est donc ni connexe ni circulaire 3.2.2 Le plan du site A partir de l'analyse prcdente et de l'application nous en dduisons facilement le plan du site. Pour effectuer ce plan, il est important de se focaliser sur les grandes fonctions du site intranet. Le ou les services que l'application nous offre pour pouvoir effectuer la gestion

       

   2 1 

de nos salles de runion. C'est une analyse des fonctionnalits de notre application.

Figure 11 - plan du site intranet

Cela correspond au formulaire de connexion l'application, la page principale, le rapport des approvisionnements, le dplacement dans le temps et les pages de rservation simple ou rcurrente d'une salle.

3.3 La base de donnes

Un des fondements d'une application dynamique est le couplage fort entre l'application web et la base de donnes. Je prsente ici l'analyse effectue sur la base de donnes et son systme de gestion afin de pouvoir reconstruire les lments cl de l'application comme le Modle Conceptuel de Donne. L'analyse nous prsentera le fichier physique de notre base, le schma de la base et les tables proposes. Nous aborderons ensuite les aspects de maintenance et de scurit (backup) de notre base. 3.3.1 Le gestionnaire de la base de donnes Nous l'avons dcouvert prcdemment que le moteur de notre base de donne est un "simple" Access 7.0 de Microsoft. Cela aura au moins l'avantage de me facilit la lecture puisque l'ensemble est graphique. La lecture du schma de la base nous propose quatre tables et une requte prdfinie. Bien sure il n'y a ni trigger, ni fonction, rien d'autres que ces quatre tables et sa requte. Le fichier MDB fait presque dix-huit mga-octets (18Mo). Il est sauvegard tout les soirs ainsi que code source de l'application par un serveur de sauvegarde ddi utilisant des bandes magntiques. Hormis ce backup, il n'y a aucun autre plan de
           25 

restauration de prvu, ce qui n'est pas forcment mauvais puisque l'application n'a absolument rien de critique. 3.3.2 La base de donnes Dtaillons plus en avant les tables afin de dcouvrir et de reconstruire les modles logique et conceptuel de donnes. Nous avons quatre tables qui sont: room reservation recurring administrator Le tableau suivant rcapitule les informations issues soit du systme d'exploitation pour dfinir la taille physique de la base, soit du schma de la base de donnes.

Nombre Volume du d'attribut schma de la table (en Ko) administrator 3 116 room 6 116 reservation 18 136 recurring 20 120 Nom de la table

Volume des donnes (en Ko) 4 4 4114 8

Nombre d'occurrence

2 19 30446 60

Table 1 - Description des informations physiques des tables

Le volume total des donnes utiles avoisine les 4350 Ko soit 4,35 Mo. Ce qui dnote franchement avec la taille de la base de donnes qui fait prs de 18 Mo. Il semble qu'il n'y a jamais eu de maintenance complte sur cette base de donnes et qu'un nombre assez important de donnes a t supprim et qu'aucune dfragmentation de la base n'est jamais t faite. On voit ici une des caractristiques de ce type de base de donnes que de croitre sans s'optimiser naturellement. On peut donc aisment supposer que ni une maintenance des donnes ni une optimisation des tables n'ai jamais t effectues. Avanons un peu plus dans la dcouverte de nos tables et dcrivons-les.

       

     

La table "Administrator" administratorid Autonumber - Long Interger Administratoruser Text 50 Administratorpassword Text 50
Table 2 - Description de la table "Administrator"

no duplicate

La table "Recurring" RecurringId RecurringName RecurringType RecurringFreq

Autonumber long Integer Text 50 Number Long Integer Number Long Integer

1 = weekly 2 = monthly 1 = every week 2 = every other week 3 ..

RecurringStartTime RecurringEndTime Recurring_RoomID RecurringDuration RecurringDayOfWeek RecurringWeekOfMont h RecurringCoffee RecurringFris RecurringBreakfast RecurringLunch RecurringText RecurringAmount RecurringMeetingEx RecurringmeetingRem arks RecurringCaseNum RecurringEmail

Number Long Integer Number Long Integer Number Long Integer Number Long Integer Number Long Integer Number Long Integer Text 50 Text 50 Text 50 Text 50 Text 50 Number Long Integer Text 50 Memo Text 100 Text 100

Table 3 - Description de la table "Recurring"

       

    2 

La table "Reservation" ReservationId

Autonumber Long Number ReservationName Text 50 ReservationDate Date - Time ReservationStartTime Number - single ReservationEndTime Number - single Reservation_RoomId Number - Long integer ReservationCoffee Text 50 ReservationFris Text 50 ReservationLunch Text 50 ReservationBreakfast Text 50 ReservationText Text 50 ReservationAmount Number - Long integer ReservationRecurringId Number - Long integer ReservationEmail Text 50 ReservationCheck Text 50 ReservationMeetingEx Text 50 ReservationmeetingRemarks memo ReservationCaseNum Text 100
Table 4 - Description de la table "Reservation"

La table "Rooms" Roomid Autonumber long integer Roomnaam Text 50 Roommax Number - Long integer Roomtext Text 50 Roomlocation Text 50 Roomtype Number - long integer

Nom de la salle

1=Aguesseau 2=Surene 1=normal room gebouw1 2=VP room gebouw1 3=normal room gebouw2 4=VP room gebouw2

Table 5 - Description de la table "Rooms"

Une lecture approfondie nous permet de dcouvrir quelques spcificits de ces tables que je vais passer en revue. La table Administrator: Elle n'est pas lie aux autres tables. C'est un cas classique des applications Web faisant appel une table pour grer les comptes de login une application lorsque l'application n'est pas connecter un systme de gestion des comptes d'entreprise comme un LDAP.
             

La table Recurring: Cette table possde onze attributs que l'on retrouve dans la table rservation. La table Rservation: Cette table possde douze attributs prsents dans la table Recurring. (les onze prcdents plus l'ID de recurring). La table Rooms: L'attribut "Roomnaam" n'est pas atomique. En effet, l'entretient avec les utilisateurs me donne la cl de cet attribut. Prenons la premire assertion de cette table "Boston A-20 + Beamer". Il est constitu du nom de la salle "Boston", puis de la lettre "A" pour la premire lettre de l'immeuble o est localis la salle, en l'occurrence "Aguesseau". Puis du nombre de personne maximum que celle-ci peut contenir "20" et enfin si celle-ci est quip d'un projecteur vido "Beamer". Ce qui nous donne pour cette attribut: "Boston A-20 + Beamer". L'attribut "Roomtext" est non utilis, il ne sert donc rien. L'attribut "Roomlocation" est du type texte de taille 50. Mais en faite ne contient que des "1" ou "2". A la vrification dans le code source, ces "1" et "2" sont traduis par le nom du btiment qui les abrite. Ce n'est pas judicieux car cela oblige l'application traduire ce champs et d'autre part l'entreprise tant trs active un autre btiment peux tre ajout contenant des salles de runion. Cela se traduirait par une modification obligatoire du code. En utilisant pleinement ce champ texte en y introduisant le nom du btiment directement, on pourrait viter au code d'effectuer une opration inutile et des problmes de maintenance du code. Dans l'ensemble, les types de champs utiliss ne semblent pas toujours opportuns. L'utilisation de champs de type "text" est sur-utilis comme par exemple pour l'attribut "ReservationBreakfast" qui est du type "text" et qui en faite devrait tre boolen. L'utilisation du type Boolen peut concerner jusqu' dix attributs de la base. Cela est d'autant plus vrai qu' la vrification dans le code source de l'application, celui-ci traduit systmatiquement le texte "yes" par une image "sticker" vert signifiant un oui. De plus, la taille de ces champs ne fait aucun doute sur le faite qu'elle n'a pas t l'objet d'une attention et qu'elle a t choisi large pour palier d'hypothtique problme ou modification. Le problme suivant qui retient mon attention est celui concernant ces attributs prsent la fois dans les tables
             

"Rservation" et "Recurring". Cela ressemble un hritage entre l'une et l'autre des tables, et c'est le cas. Nous avons ici un hritage car la rservation rcurrente est une sorte de rservation simple. A la lecture du contenu des tables, nous retrouvons plusieurs occurrences dont de nombreux attribut sont gaux entre ces deux tables "Recurring" et "Reservation" avec un Id commun qui est "Recurringid" gal "ReservationRecurringid". La lecture des donnes nous apprend aussi que des informations issues de la table "Reservation" diffre de la table "Recurring". Nous trouvons l'explication dans le code source et dans l'interview effectu auprs des htesses chargs d'utiliser l'application. Il est possible une fois la rservation rcurrente effectue de modifier une occurrence pour ajuster la demande de l'utilisateur en ajoutant ou supprimant la prsence d'un service (caf par exemple). Une lecture plus approfondie encore du code source vrifi ensuite par des tests sur l'application me rvle qu'une fois faite, la rservation rcurrente ne peux plus tre modifi. Mieux encore, suite un dfaut de programmation il n'est pas possible non plus de la supprimer. Alors la question se pose, est-il vraiment ncessaire d'avoir tout ces attributs en doublon dans nos deux tables ? C'est une nouvelle fois le code source qui nous donnera la rponse. Les informations redondante entre les deux tables sont temporaire dans la table "Recurring" afin de crer toutes les occurrences ncessaire dans la table "Rservation". L'occurrence de la table "Recurring" ne devenant utilisable plus que pour la supprimer en supprimant toutes les occurrences crer dans la table "Reservation". Ce qui comme je viens de le dire ne sert rien puisqu'un dfaut de programmation empche de visualiser la rservation rcurrente que l'on vient de crer. Les attributs en doublon sont donc inutile et doivent tre grer par l'application lors de la cration d'une rservation rcurrente. Par contre, les autres attributs de "Recurring" doivent servir pouvoir slectionner correctement la rservation rcurrente que l'on souhaite supprimer. Ces attributs sont donc utile, et le formulaire de suppression doit tre rcris en consquence. L'indexation des identifiants des tables existe mais MS Access ne permet pas aisment de retrouver leur lieu de stockage, leur taille ou toutes autres informations. Enfin, un autre problme survient qui me gnera tout au long de la reconstruction Je ne parle pas le nerlandais. C'est donc un problme de taille car l'utilisation de plusieurs langues dans la base et dans le code source cre une difficult de comprhension. On le voit donc clairement, la base de donnes ne semble pas avoir fait l'objet d'un travail srieux de mise au point. Les tables
             

ne sont pas normalises, le type des attributs n'a pas t choisi consciencieusement et les tailles des types d'attribut non plus. Enfin, nous avons des donnes qui peuvent tre en doublon et qui seront de toute manire inutile immdiatement aprs la cration des occurrences ncessaire dans la table "Reservation". Pourtant il y a ici une optimisation de la base qui mrite quand mme d'tre signale. L'aplatissement des attributs de service, ceux en doublon entre les tables "Reservation" et "Recurring". Cette aplatissement permet un gain et optimise ainsi la base et le traitement par l'application. Cela a-t-il t volontaire ? J'en doute vu le peut d'attention apport cette base mais le souligne ici. Les tableaux suivant prsentent pour l'exemple quelques occurrences des tables sauf pour la table "Administrator"

       

     

Exemple Reservation:
Reservation Id Reservation Name Reservation Date 29/05/2001 Reservation StartTime 7,75 Reservation EndTime 15 Reservation _RoomId Reservation Coffee Reserva tion Fris Reservation Lunch yes Reservation Breakfast yes Reservation Text 20 pts dej Pause 10h45 cafe the biscuits 20 petits dej Lina's pour 20 pers 20 petits dej 10h30 Lina's pour 20 pers 14 petit dej+17 plateaux mixte+2 thermos 13h OK Reservation Amount 20 Reservation Recurring Id Reservation Email 0 Candelon francois 0 Angela Paul 0 Angela Paul 0 BONNEFOI Yes Reunion avec des personnes de BCG Melbourne Reunion aves des personnes de BCG Melbourne Reservation Check Reservation Meeting Ex Reservationmeeting Remarks Reservation CaseNum 21123/08

2497 cf

2570 AP 2571 AP 24239 NB

12/06/2001 13/06/2001 07/09/2004

8 8 8

20 20 17,5

10 yes 10 yes 10 yes 22 yes yes yes yes yes yes yes 20 20 20

15204/51 15204/51 21038/33

Exemple Room:
RoomID 1 2 4 5 6 7 8 9 10 11 13 15 22 23 24 25 27 28 29 RoomNaam Boston A-20 + Beamer Buenos Aires A-4 Londres A-6 + Beamer Moscou A-3 Munich A-3 Shanghai A-4 Miami A-12 Plasma + VideoConf Kuala Lumpur S-8 + Beamer Grande Salle S-150 Paris A-12 + Beamer Jakarta (316) S-4 Tokyo A-12 Atlanta RJ S-50 + 2 Beamers Lisbon RJ S-14 + Beamer Oslo RJ S-18 + Beamer Sao Paulo (121) S-4 + TV/VHS San Francisco 114 S-16 Sur Formation Anglais 1 Sur Formation Anglais 2 RoomMax 25 4 8 3 3 5 12 8 150 12 4 12 50 14 18 4 16 1 1 RoomText RoomLocation RoomTYpe 1 1 1 1 1 1 1 1 1 1 1 1 1 1 2 1 2 1 1 1 2 1 1 1 2 1 2 1 2 1 2 1 2 1 2 1 2 1

Exemple Recurring:
Recurring Name AG rec REC REC REC REC REC REC REC REC REC REC REC REC REC REC REC EP EP CC DP EG CH PL JGP CG DP Recurring Id 128 129 130 131 132 133 134 136 137 138 139 140 142 143 144 145 146 148 150 152 153 154 155 156 158 159 160 Recurring Type 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 0 0 0 0 0 0 0 0 0 0 Recurring Freq 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 0 0 0 0 0 0 0 0 0 0 Recurring StartTime 12 12 12 12 12 12 12 12 12 12 12 12 12 12 12 12 12 12 12 8 7 8 10 14 14 10 7 Recurring EndTime 14 19 19 19 19 19 19 19 19 19 19 19 19 19 19 19 19 14 14 18 22 22 12 15 15 11 22 Recurring _RoomID 9 2 2 4 5 6 7 4 5 6 7 2 4 5 7 6 5 4 4 1 18 12 6 12 8 7 19 Recurring Duration 4 52 52 52 52 52 52 52 52 52 52 52 52 1 52 52 52 2 1 1 1 1 2 1 1 1 4 Recurring DayOf Week 6 2 4 4 4 4 4 2 2 2 2 6 6 6 6 6 6 0 0 0 0 0 0 0 0 0 0 Recurring WeekOf Month 0 Recurring Coffee Recurring Fris Recurring Breakfast Recurring Lunch yes Recurring Text Recurring Amount 10 2 Yes 2 Yes 2 Yes 2 Yes 2 Yes 2 Yes 2 Yes 2 Yes 2 Yes 2 Yes 2 Yes 2 Yes 2 Yes 2 Yes 2 Yes 2 Yes yes yes Lina's (voir e Riva ) 6 6 11 4 6 2 2 2 3 5 PO Gervais Constantia petrou W Zein C Landi MMM formation roll out windows 2000 Formation roll out windows 2000 FINANCIAL GILEAD interne cours d'anglais ADM/PAR-00 22118/00 Recurring MeetingEx Recurring Meeting Remarks Recurring CaseNum 21625/08 RecurringEmail Gourevitch RECRUITING REC REC REC REC REC REC REC REC REC REC REC REC REC REC REC PENVEN Edwige PENVEN Edwige CALONNE CLEMENTINE Picard david Guillet edouard HALLEZ charlotte POMMIER Laurent PELADAN GARNIER PICARD david

CL

161

11

14

0 yes 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 10 14 2 0 30

MMM

L'analyse des tables de la base de donnes "Gestion des salles de runion" permet d'en dduire le modle logique de donnes suivant. Il est le reflet des tables en production dans notre base.

Figure 12 - Le MLD reconstruit

Issue du modle logique de donnes nous effectuons une volution de ce schma vers le modle conceptuel de donnes. Ce travail nous permettra par la suite de comprendre le fonctionnement de l'application et de pouvoir y porter les modifications attendues et demandes. Mais aussi les modifications ncessaires afin de rendre la base de donnes et le table normalises avec un fonctionnement optimal. Ce qui contrairement aux interviews n'est pas le cas

Figure 13 - Le MCD reconstruit

Les informations recueillis ne permettent pas d'entrevoir une sparation entre les donnes fixe et dynamique. On le voit, la base gre les donnes dynamiques, mais rien ne gre les donnes fixes. Et la lecture du code source me confirme que rien n'a t prvu. 3.3.3 Analyse des requtes SQL L'analyse des requtes faites sur les tables de la base montre que la table "administrator" n'est requte que pour vrifier l'accs l'application via le login afin de donner des accs de lecture-criture l'utilisateur. Aucune autre requte n'est effectue sur cette table. Les autres requtes sont pour la plus part du temps des jointures entre les tables. L'application gre l'intgrit entre les tables lorsqu'une suppression est effectue et qu'une rplication de cette suppression est ncessaire. L'application effectue donc une partie du travail qui devrait revenir la base de donnes. Plusieurs requtes ramne beaucoup plus d'information que ncessaire (exemple avec les pages "Coffee.asp" et "rec_form_delete.asp"). Le rsultat se solde soit par une impossibilit d'effectuer l'opration dans le cas de la suppression d'une rservation rcurrente ou l'affichage d'information inutile dans le cas de la gestion des approvisionnements.

Il n'y a pas de requte d'insert ou d'update proprement dite mais le dveloppeur utilise les fonctions internes lis l'ASP pour effectuer des updates, cela alourdit considrablement le code source. Voici pour exemple la manire utilis par le dveloppeur pour effectuer un "Update" d'une table.
sql2 ="select * From Reservations where ReservationId=0" rstSave.open sql2,Session("LinkToDatabase"),1,3 rstSave.AddNew rstSave.fields("ReservationName") = request("RecurringName") rstSave.fields("ReservationDate") = res(x) rstSave.fields("ReservationStartTime") = request("RecurringStartTime") rstSave.fields("ReservationEndTime") = request("RecurringEndTime") rstSave.fields("ReservationCoffee") = request("RecurringCoffee") rstSave.fields("ReservationFris") = request("RecurringFris") rstSave.fields("ReservationBreakfast") = request("RecurringBreakfast") rstSave.fields("ReservationLunch") = request("RecurringLunch") rstSave.fields("ReservationmeetingRemarks") = request("RecurringmeetingRemarks") rstSave.fields("ReservationMeetingEx") = request("RecurringMeetingEx") rstSave.fields("ReservationCaseNum") = request("RecurringCaseNum") rstSave.fields("ReservationEmail") = request("RecurringEmail") rstSave.fields("Reservation_roomid") = request("Recurring_roomid") rstSave.fields("ReservationAmount") = request("RecurringAmount") rstSave.fields("ReservationText") = request("RecurringText") rstSave.fields("ReservationRecurringId") = RecurringId rstSave.Update rstSave.close msg = "The reservation is made.<br>"

L'utilisation de ce code pour effectuer des modifications dans la base de donnes laisse penser que le dveloppeur peu ou pas du tout de connaissance en SQL. Ce qui pourrait expliquer le MCD de la base, des requtes toujours du mme niveau de complexit et pas toujours juste. Il n'est plus possible par exemple de supprimer une rservation rcurrente, soit par ce que l'interface ne le permet pas, soit par ce que la requte prend en compte toutes les rservations rcurrente mme pass au lieu des futurs ou en cours D'autre part, des requtes sont dupliques ou triples dans certaines pages du code source. Cela traduit un manque de fonction ddi ou le manque de programmation orient objet et une grande pratique du "copier-coller". Il n'y a aucune requte pour grer les salles de runion. Cellesci ont donc t cre manuellement directement sur la base de donnes. De la mme manire pour la suppression avec l'inconvnient dj analys que l'intgrit des tables n'est pas respect puisque l'on retrouve dans la table rservation des occurrences li des salles de runion qui n'existe plus.

Enfin, la charge de travail provoque par ces requtes n'a pas t mise en vidence, le serveur ayant des ressources suffisantes pour effectuer ce travail dans un temps tout fait acceptable. Mais, mme si la charge du serveur n'a pas t mise en vidence, la conception des requtes nous permet une optimisation facile afin d'obtenir de substantiel gain de performance et un meilleur fonctionnement de certains modules dvelopps. 3.3.4 Plan de maintenance Nous l'avons vu plus haut, dans la section 3.3 Base de donnes que le plan de maintenance ne concerne que le backup par un agent ddier cet effet sur les fichiers de la base et du code source. MS Access ne permettant, en automatique, rien d'autre. Il n'y a, ni ne semble avoir eu, d'optimisation ni de dfragmentation des tables.

3.4 Analyse du code Source

L'analyse du code source nous montre l'utilisation de quatre langages diffrents pour grer cette application : HTML ASP JAVASCRIPT VBSCRIPT Il arrive mme presque toutes les pages que ces quatre langages soient utiliss en mme temps. Cela alourdit considrablement la lecture et la comprhension du code source et permet une erreur de ne pas tre dcouvert rapidement. L'utilisation de tantt l'un tantt l'autre des langages cot client me laisse penser que le dveloppeur ne maitrise en faite rellement ni l'un ni l'autre. La volont d'utiliser plusieurs langages pour interprter les commentaires, tantt en Anglais tantt en Nerlandais me laisse aussi la sensation que le dveloppeur souhaite rester propritaire de son code en y gardant une certaine opacit de lecture. Nous voyons aussi que certaines lignes de code son purement et simplement recopies dans l'tat alors que l'on aurait pu effectuer une fonction ou une routine. Le dveloppeur a des lacunes dans la connaissance des langages qu'il utilise. En voici un exemple dans la page "loginCheck.asp". Cette page a pour but d'effectuer une requte SQL en tant sure que l'utilisateur ne pourra pas la reloader. On y arrive avec des arguments

et on est automatiquement renvoy aprs notre requte SQL vers la home page. Seulement pour effectuer ce renvoi, il utilise les services d'un formulaire dont tous les champs sont cachs. De la mme manire, le programmeur utilise la fonction "javascript.history.go(-1) lorsque l'on click sur un bouton "Back" dans le formulaire de saisie d'une rservation rcurrente ("rec_form.asp") afin de revenir en arrire. Comment fonctionne ce formulaire ? En faite, il est compos de plusieurs sous-formulaire comme prsent dans les Figure 6 - Formulaire de rservation rcurrente - 1, Figure 7 - Formulaire de rservation rcurrente - 2 et Figure 8 Formulaire de rservation rcurrente - 3. Si on va jusqu'au bout du formulaire puis que l'on revient en arrire nous obtenons des effets de bord intressant puisque cliquer deux fois sur le bouton "Back" avec cette fonction reviens revenir au formulaire que l'on vient de quitter. Il n'y a pas non plus de fichier de paramtrage permettant par exemple le paramtrage de l'accs la base de donnes, ni la mise en variable de paramtrage de tout ce qui peut tre modifi lors d'une migration. Il n'a nullement t pris en compte une gestion des donnes susceptibles d'tre un jour modifi. On ne peut facilement ajouter un service sans devoir rcrire certaine page de l'application. Les variables utilises le sont gnralement en Nerlandais, ne facilitant nullement la lecture et la comprhension, tout comme les trs rares commentaires Certaines contraintes de fonctionnement list dans les rgles de construction psent lourdement sur le code. C'est le cas de la gestion des minutes qui si elle n'avait pas t traduite aurait permis un gain vident tant dans le code que dans la comprhension gnrale. Enfin, nulle volont de segment les langages de l'application afin par exemple de crer des routines d'criture HTML partir de routine ou fonction en ASP. Cela aurait gagn en lisibilit et simplicit. Il n'y a pas non plus de vritable fichier d'inclusion avec une arborescence d'inclusion pour l'accs la base, charger les fonctions ncessaire au fonctionnement ou les fonctions ncessaire l'criture HTML des pages. Cela conduit un allongement excessif de certaines pages. La page "Home.asp" faisant prs de trente et une pages papier. Ce qui alourdit la comprhension gnral. Il n'y a pas de vraie mthodologie de dveloppement et hormis l'enchanement des pages web, rien ne semble vraiment structur. Aucune notion de programmation objet, mme symbolique, ni de structuration dans l'utilisation des langages utiliss.

3.5 Reconstruction des rgles de fonctionnement

A partir du code source on peut reconstituer certaines rgles de fonctionnement utilis pour le dveloppement de l'application. 1. Une rservation ne peut tre prise pour une dure infrieure 15 minutes. 2. La dure d'une rservation s'effectue par incrment de 15 minutes. 3. Les minutes d'une rservation sont systmatiquement traduis depuis et vers la base, en dcimale. Un quart d'heure valant "25", une demi heure valant "50", trois quart d'heure valant "75" et une heure plein valant "00". 4. Une rservation peut tre effectue pour toute heure du jour et de la nuit sans aucune contrainte. 5. Une rservation rcurrente est systmatiquement cre dans la table "Recurring" avant que l'on cre les occurrences correspondantes dans la table "Reservation". 6. Possibilit de modifier un service pour n'importe quelle rservation mme rcurrente. 7. Impossibilit de modifier de manire rcurrente un service demand pour une rservation rcurrente. 8. Proposer des requtes SQL les plus simple possible pour une remont d'information la plus importante possible. Cette liste n'est pas exhaustive mais difficile de faire plus dans la jungle du code source. On imagine pourtant assez bien que toutes ces rgles ne sont pas dictes par des besoins utilisateurs.

3.6 Analyse du design utilis

A l'vidence, le programmeur a utilis plusieurs moyens pour effectuer le design du site. 1. Il a tent l'utilisation d'un CSS via un fichier ASP charg rgulirement dans certaines pages ASP, pas dans toutes. 2. Il a rgulirement introduit directement dans le code HTML des balises qui aurait du tre mis dans un fichier CSS. 3. Enfin, pour certaines prsentations, il fait appel un atelier de type "Frontpage" pour obtenir les designs recherch. On le voit, la gestion graphique de l'application c'est effectu au plus facile. Cela aurait mrit d'tre optimis par un CSS. Le fichier "Verdana.asp" semble tre d'une autre utilisation et pourrait provenir d'une autre application. En effet, on y retrouve une description des utilisations possible de la police Verdana dans diffrentes couleur dans toutes les tailles de cette police.

3.7 Analyse de la scurit

L'analyse du code nous rvle aussi que l'accs en criture est valid de la manire suivante:
<frame name="main" src="home.asp?LogIn=ok" scrolling="YES">

Malgr la ncessit d'un login, on ne peut pas dire que la scurit soit optimale. Ce qui est corrobor par le faite que l'accs au fichier MDB ne soit pas protg et que les requtes soient effectues via le compte "SA" administrateur sans mot de passe. La base n'est pas scurise, mais pour autant, cette application ne semble ne rien avoir de critique. Si ce n'est que la venue d'un client et donc la rservation d'une salle et considr comme trs importante voir prioritaire sur d'autre runion. Ce point intressant me rappelle les raisons donne pour l'amlioration de l'application, celle de pouvoir traquer ce qui se passe, qui cre ou supprime une rservation. C'est surement l la raison de cette demande.

3.8 Les besoins fonctionnels initiaux

Pas de grande surprise par rapport notre carte de l'application. On peut rsumer les besoins fonctionnelles par : un login l'application la rservation simple d'une salle de runion la rservation rcurrente d'une salle de runion la commande au travers d'une rservation de service annexe (caf, boisson, ...) la gestion des approvisionnements des salles en fonction des dites commandes la possibilit de supprimer une rservation rcurrente le dplacement dans le temps pour visualiser l'agenda des salles la visualisation de l'agenda d'une salle un jour donne

3.9 Les besoins non fonctionnels initiaux

Malgr mes recherches, il ne m'a sembl qu'un seul besoin avait t assouvi. Mais ce besoin semble plus un souhait du dveloppeur qu'une demande du MOA ou des utilisateurs. Ce souhait russi est de rendre la comprhension du code le plus complexe possible et donc indispensable la prsence et la relation avec le dveloppeur de cette l'application J'ose esprer que je me trompe

3.10

Les besoins initiaux non couvert

A prime abord, Il semble qu'un certain nombre de pages lies l'administration du site ont t oublies dans la livraison de l'application. Il n'y a pas de page d'administration du site pour grer les salles de runion, ni grer l'historisation (annuelle) des rservations. On peut mme supposer qu'une analyse relle des besoins des utilisateurs du site (la rception) aurait conduit des modifications ou la cration d'interface spcifique pour la gestion des rapprovisionnements par exemple. Du point de vue des besoins non fonctionnels, on ne peut pas dire que l'application permette la gestion des salles de runion avec srnit. De nombreux bug vient perturber le bon fonctionnement de l'application, on n'est pas toujours sure de ce que l'on fait et on ne sait pas si une erreur humaine puisse tre prvisible et dtect suffisamment tt. Ce qui je pense conduit un nouveau besoin initial, celui de sauvegarder dans un log systme ou archivage toutes les actions qui sont effectus. Il n'est pas certain non plus que le moteur MS Access permette des traitements SQL rapide. Au vue de la gestion de ce projet tant du cot MOA que MOE il est clair qu'aucun concept de besoin non fonctionnelle n'est t pris en compte.

3.11

Analyse de la reconstruction
La reconstruction que nous venons d'effectuer nous a permis de reconstruire le puzzle de notre application au travers des fichiers ASP de l'application, du SGDB et de la base. Il n'est pas toujours simple de comprendre aprs coup et sans autres informations les motivations des dcisions qui ont conduit ce rsultat. Pourquoi une base Access ? Est-ce par mconnaissance du moteur MS SQL ? Estce par ce que le dveloppeur n'avait pas de licence MS SQL ? Est-ce pour des raisons de maintenance de la base Par contre, et on vient de le voir, notre esprit critique nous permet d'envisager l'architecture complte de l'application sous un jour diffrent. Les manquements important dans la conception, la ralisation et mme dans la livraison (puisqu'il manque au moins un module d'administration) nous dmontre que non seulement le MOA ne connaissait rien au dveloppement web, qu'il n'entendait rien non plus la gestion d'un projet de cette nature et qu'il n'tait encore moins l'utilisateur final car sans quoi, il se serait rendu compte de quelque chose Tout compte fait, ce n'est peut-tre pas un MOA

4 Qualit de l'application
Il est intressant dans un projet de reconstruction de confront le rsultat obtenu des critres de qualit. Cela mme que nous nous serions appliqu lors de la conception comme but obtenir. A la diffrence que l, ce n'est plus l'objectif que l'on se fixe mais le rsultat obtenu que l'on value. Pour la notation, j'utiliserai le modle suivant. 1 correspond la meilleure note possible et 5 la plus mauvaise. Il s'agit de note subjective bas sur le ressenti plutt que qualitative par rapport un modle mathmatique par exemple car l'application est petite et le modle conceptuelle est simple. Il n'est donc pas ncessaire de se report une modlisation plus complexe de la qualit que celle du ressenti. Je noterai dans un premier temps la qualit des donnes puis celle du Systme d'Information travers sa base, le code source et la structure fichier de l'application. Les critres de qualit des donnes sont prsents ici: Fiabilit confiance accorde aux donnes Fracheur comparaison date saisie et date du jour Compltude taux de valeurs non manquantes Exactitude taux de valeurs correctes Validit par rapport un format, type, etc Crdibilit vraisemblance Actualit taux de valeurs non obsoltes Disponibilit facilit d'accs Cohrence par rapport un ensemble de contraintes Fiabilit Fracheur Compltude Exactitude Validit Crdibilit Actualit Disponibilit Cohrence
Table 6 - Qualit des donnes

2 3 4 2 4 4 3 3 4

Puis, c'est sur l'application que je porterai mon jugement en notant la qualit de la base de donnes puis le code source de l'application. Pour cela, j'utiliserai les critres rserv un Systme d'Information, la base pouvant tre considr comme un sous systme d'information.

Les dimensions de la qualit d'un SI sont les suivantes: Facteurs de fonctionnement o l'exactitude, la fiabilit, l'efficience, l'intgrit l'utilisabilit Facteurs d'volution o la maintenabilit, la flexibilit et la testabilit Facteurs d'adaptation o la portabilit, la rutilisabilit et l'interoprabilit Deutsch & Willis o la scurit, la manageabilit, et la survivabilit

et

Les facteurs de fonctionnement de la base de donnes. l'exactitude 3 la fiabilit 5 l'efficience 4 l'intgrit 5 l'utilisabilit 4
Table 7 - Les facteurs de fonctionnement de la base de donnes

Les facteurs d'volution de la base de donnes. la maintenabilit 4 la flexibilit 4 la testabilit 4

Table 8 - Les facteurs d'volution de la base de donnes

Les facteurs d'adaptation de la base de donnes. la portabilit 5 la rutilisabilit 5 l'interoprabilit 5

Table 9 - Les facteurs d'adaptation de la base de donnes

Les facteurs de Deutsch & Willis appliqu la base de donnes. la scurit 5 la manageabilit 4 la survivabilit 5
Table 10 - Les facteurs de Deutsch & Willis appliqu la base de donnes

J'ai souhait aussi noter les lments suivant de la base de donnes Pertinence des requtes 3 simplicit du schma 2 exactitude des types de donnes 4 compltude des besoins utilisateurs 3 documentation de la base 5 maintenabilit de la base 4
Table 11 - Qualit de la base

Ces dimensions viennent bien corrler l'apprciations faite jusqu'ici. Puis je note la qualit du code source en appliquant les mmes critres, ceux du Systme d'Information. On supposera comme pour la base de donnes que le code source reprsente un sous systme d'information du SI applicatif. Les facteurs de Deutsch & Willis appliqu la base de donnes. l'exactitude 4 la fiabilit 5 l'efficience 4 l'intgrit 5 l'utilisabilit 4
Table 12 - Les facteurs de Deutsch & Willis appliqu la base de donnes

Les facteurs d'volution du code source. la maintenabilit la flexibilit la testabilit

Table 13 - Les facteurs d'volution du code source

4 4 4

Les facteurs d'adaptation du code source. la portabilit la rutilisabilit l'interoprabilit

Table 14 - Les facteurs d'adaptation du code source

5 5 5

Les facteurs de Deutsch & Willis appliqu au code source. la scurit 5 la manageabilit 4 la survivabilit 5
Table 15 - Qualit du code source

Pour la structure de l'application, il est plus complexe de noter la qualit de celle-ci car je ne peux pas certifier que cette application n'ai pas t modifie par une tierce personne depuis sa livraison. Je me bornerai qualifier les lments suivant. utilisation des concepts de gestion graphique standardise conformit une arborescence connexe conformit une arborescence circulaire
Table 16 - Qualit de la structure fichier

4 2 5

Enfin, j'effectuerai une qualification globale de l'application telle qu'on peut la ressentir la lecture des lments prcdents. La base Le source La structure avis utilisateur
Table 17 - Qualit de l'application

4 4 4 1

J'ai choisi de prendre en compte l'avis utilisateur qui va l'encontre de mon ressenti de la qualit de l'application car c'est surtout eux qui utilise au quotidien ce site web. L'ensemble des notes portes sont corrles avec les lments dcrit lors de la reconstruction de l'application au chapitre 3 page 15.

5 Les volutions ncessaire issue de la reconstruction

La reconstruction que nous venons d'effectuer ainsi que de son analyse nous amne penser des volutions ncessaire au bon fonctionnement de l'application afin de pouvoir intgrer au mieux les nouvelles fonctionnalits demandes.

5.1 L'architecture systme

La modification qui sera effectu sera de migrer le SGBD vers un serveur MS SQL. L'application ne ncessite pas un tel niveau de disponibilit, de scurit ou de reprise en cas de panne mais cela permettra une homognisation avec les autres applications de l'entreprise permettant ainsi aux quipes en place de prendre le "contrle" sur l'application. Il n'y aura pas d'autre modification come par exemple pour le serveur WEB, les entres DNS,

5.2 L'architecture des pages web

La structure des pages web sera modifie pour faire disparatre les tentatives de maintenance du site ainsi que les erreurs de programmation rfrences. Nous ferons apparatre ce stade une page d'administration du site qui est grandement ncessaire pour grer les salles de runion. On remarquera que le graphe est connexe et que les retours se font correctement vers la "home page".

Figure 14 - Nouvelle structure des fichiers source

5.3 Base de donnes et optimisation

Suite la reconstruction effectu sur le SGBD et la base de donnes et aux diffrentes remarque effectu, nous allons modifier cette ensemble afin de le rendre conforme aux bonnes pratiques et normalis. 5.3.1 Le SGBD La premire pens est de migrer notre base de donnes sur le moteur MS SQL plutt que de le laisser sur Access 7.0. L'avantage sera la mise en uvre de trigger et de fonction qui permettront de dcharger l'application d'une partie de la gestion de la base comme par exemple lors de la suppression d'une salle de runion, de la suppression d'une rservation rcurrente ou encore lors de l'archivage dans les logs (fonction demand par le MOA) d'une modification effectue sur une rservation. L'application de ces quelques rgles permettra d'obtenir une meilleure intgrit de la base et des donnes. La base de donnes

5.3.2

C'est maintenant, fort de nos interrogations et propositions faite plus haut que nous allons modifier notre MCD pour le rendre conforme au rel que nous souhaitons avoir en y ajoutant les modifications ncessaires et demandes. C'est le MCD suivant.

Figure 15 - Le nouveau Modle Conceptuel de Donnes

La premire remarque que l'on peut faire est que tous les noms d'attributs on chang afin de reflter le caractre international de l'entreprise. Cela doit permettre un dveloppeur d'une culture international (mme Nerlandais) de pouvoir effectuer de nouvelles modifications si cela devenait ncessaire. J'ai suivit mon raisonnement sur les attributs en doublon et ils ont disparu de la table "Recurring".

5.4 Le code source

Trois oprations vont tre effectues en priorit. La premire opration sera le "refactoring" qui va consister en la restructuration du code afin de le simplifier, de l'optimiser et de le documenter. On utilisera des fonctions ASP afin d'crire le code HTML en prenant en compte l'existence d'un fichier de dfinition de

la charte graphique travers le CSS. On crera aussi des fichiers d'inclusions ddi aux diffrents langages utilis dans le code. La seconde opration sera de dbugger et de redvelopper les pages pour que les retours sur la page "Home" se fasse correctement et que le dveloppement soit conforme aux bonnes pratiques de la programmation WEB. Mais aussi de mettre en uvre plus de contrle des champs par l'utilisation du "JavaScript". Enfin, la troisime grande opration sera la mise en uvre des fonctionnalits demandes ou manquantes (comme les pages d'administrations). Quoi que pas tout fais adapter ce contexte de dveloppement, je conseille quand mme d'effectuer une programmation de type objet afin de mieux organiser la rutilisation des lments, d'avoir un code mieux structurer, plus claire et aussi plus facile par la suite modifier. Cela ncessite de revoir plus amont les besoins des utilisateurs afin de dcrire cela dans divers diagrammes UML.

6 Les bonnes pratiques du dveloppement WEB

On ne peut pas reconstruire une application WEB sans penser la phase suivante de Forward Enginering et l'utilisation des bonnes pratiques de dveloppement spcifiques au mode WEB. L'utilisation des bonnes pratiques du WEB peuvent avoir un impact positif et significatif sur l'ensemble d'un projet. Ces bonnes pratiques peuvent tre trouves sur internet et ont pour focus toutes parties de l'application et du projet. J'en cite quelque uns principaux et commun mais chaque type de projet WEB peut avoir les siennes avec des spcificits financire, scurit...

6.1 Mise en forme - CSS

Nous en avons dj longuement parl, mais ce point est si important que je n'hsite pas. L'utilisation de CSS fait gagner en simplicit, clart et efficacit. Elle a aussi un impact positif lors de la reconstruction, le projet peu alors se voir ajouter un module ddier au graphisme du site. Il faut donc l'utiliser en prfrence toute autre possibilit.

6.2 Base de donnes et optimisation

Une base de donne bien dfini avec une sparation claire entre les donnes et les traitements y compris les triggers ou fonctions pour assurer l'intgrit d'un cot et l'application de l'autre est primordial. Il faut viter le plus possible de coder en dur des informations variable ou des lments devant grer l'intgrit des bases Il faut rendre Csar ce qui lui appartient... de faire.

6.3 Conformit du site

Faire valider son code HTML par une DTD. <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional // EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> C'est une excellent faons de s'assurer que son code est valide, et nous avons vu que le notre ne l'tait pas.

6.4 Interfaces
Il arrive trop souvent dans un application web de devoir jongler entre clavier et souris. Une bonne interface doit pouvoir tre traiter au clavier seul, le faite de devoir utiliser la souris pour ce positionner sur le champ remplir n'est pas une bonne pratique. D'autre part, une interface ne dois comporter d'information que pour ce qu'elle est cens faire. Il n'est donc pas normal de voir un formulaire "crer une runion rcurente" comporter un bouton supprimer une rservation rcurrente.

6.5 Code source HTML

Ferm systmatiquement les balises vides. Par consquent, ne pas crire <br> mais <br /> ou ne pas crire <hr> mais <hr />. Ecrire tous les attributs en minuscule et dans un formulaire, ne pas utilis l'attribut checked mais checked="checked". Ces points faisant partie du standard de dfinition du W3C pour le WEB.

6.6 La gestion des diffrents langages utiliss

Il va aussi de soit qu'il faut prendre en compte que d'autre viendront relire et modifier notre travail. Dans un contexte international, une fusion peut intervenir et vous vous retrouver avec un code dans une langue que vous ne maitrisez pas. Utiliser l'Anglais comme langue international commune est primordial dans le cadre d'une entreprise prsent sur les cinq continents et dans 60 pays dans le monde.

6.7 D'autres bonnes pratiques du web

On pourrait citer l'utilisation d'UML pour la conception, l'utilisation de classe ou code objet (mme partiellement objet pour de l'ASP ou du PHP) afin d'avoir un code source propre, simple maintenir et lisible sans effort.

On pourrait aussi citer l'utilisation du langage ASP pour l'criture du code HTML afin de clarifier et simplifier le code source par appel de fonction. Pour exemple, une fonction "Debut_Formulaire()" pour gnrer en HTML le code ncessaire l'criture du dbut du code d'un formulaire. Plus lisible, on pourrait moins facilement oublier de ferm celui-ci. D'autre part, l'utilisation du JavaScript cot client pour effectuer les vrification d'usage plutt que de les faire cot serveur ferait gagner l'application en performance, la bonne sparation entre ce qui doit tre fais cot client du cot serveur est importante et merite d'tre respect.

7 Conclusion
Le dclencheur d'une demande de reconstruction d'une application WEB est souvent une demande d'ajout de fonctionnalit. Malgr la simplicit de l'application, par sa base de donne ou le nombre de ligne du code source, cette reconstruction aurait presque pu tre scinde en deux projets distincts. Le premier pour reconstruire l'application et le second pour y effectuer les ajouts ncessaire tant l'application ncessite de modification ou de changement. Nous avons pass en revue l'ensemble des lments (infrastructure, base de donnes, schma de la base, structure fichier, code source, design graphique de l'application,) a travers diffrent filtre, tantt pour contrler la qualit des lments, tantt technique pour valider les choix effectuer, tantt smantique pour valuer la manire dont cela avait t cris, tantt conceptuel pour valider la conformit du model l'exactitude du rel ou la compltude. L'intrt de ce travail t de prsenter ou proposer des manires de faire suivant l'lment mis en lumire pour effectuer cette reconstruction. Au del de la manire d'effectuer cette reconstruction c'est en faite le fait que la reconstruction est constitu de plusieurs sous module pourtant chacun leur propre nom et fonction comme le "Design Recovery", la "Redocumentation", le "Restructuting" ou encore le 'Refactoring". Dans l'tat actuel de notre application, difficile de passer coter de tous ces modules de la reconstruction. Mais la reconstruction un cot non ngligeable qui ne faut oublier. Cette lment financier est primordial car il doit permettre de choisir s'il faut effectuer cette reconstruction ou s'il vaut mieux repartir dans une approche plus classique du "Forward Engineering". Ce choix peut-tre guid par diffrents facteurs dont la qualit d'une application ou celle de la base, faut-il encore se pencher dessus pour s'en faire une ide. Facteur qualit qu'il faudra associer au temps pass dcortiquer l'application.

8 Annexe
Les annexes suivantes sont soit des fichiers complets ou des morceaux choisi afin d'illustrer la ralit du code source.

8.1 Listing du fichier "Dlogin.asp".

<% response.expires=0 %> <html> <head> <title>BCG Room Reservation System</title> <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"> </head> <frameset cols="0,*" frameborder="yes" border="0" framespacing="0" rows="*"> <frame name="tool" src=""> <%if request("LogIn")="ok" then %> <frame name="main" src="home.asp?LogIn=ok" scrolling="YES"> <%else%> <frame name="main" src="login2.asp" scrolling="no"> <%end if %> </frameset> <noframes> <body bgcolor="#FFFFFF"> </body></noframes> </html>

8.2 Listing du fichier "Login2.asp".

<!--#include file="acces_base.inc" --> <%response.expires=0 %> <html> <head> <title>Buk-a-Rum</title> </head> <script> function PositionDiv() { if (document.body.offsetWidth > 800 && document.body.offsetWidth < 1024 ) { document.all.menu.style.width= document.body.offsetWidth-24 } else if (document.body.offsetWidth >= 1024) { document.all.menu.style.width= 1000 } else { document.all.menu.style.width = 776 } } </SCRIPT> <link rel="stylesheet" href="verdana.asp"> <body onload="PositionDiv()" onresize="PositionDiv()" bgcolor="FCFDF1" background="img/bg.jpg" leftmargin="0" topmargin="0" marginwidth="0" marginheight="0" link="#333333" vlink="#333333" alink="#333333" > <DIV ID="menu" style="position:absolute; top:0px; left:0px; width:100%;"> <table width=100% background=img/top.jpg height=78> <tr> <td>&nbsp;</td></tr> </table> <table width=100% border=0 cellpadding=0 cellspacing=0>

<tr> <td background=img/nav.gif align=left> <table width=97% border=0 cellpadding=0 cellspacing=0> <tr> <td class=v10 >&nbsp;&nbsp;&nbsp;<b>Today:</b> &nbsp;<%=FormatDateTime(now(),vblongdate)%></td> <td class=v12 align=right> <b><font color=ffffff>BCG Reservation System</font></b><br></td></tr> </table></td> <td background=img/nav.gif> <img src=img/nix.gif width=10 height=23></td></tr> </table> </div> <div id=tijdschaal Style="width=720;visibility:visible;left:14;top:130;position:absolute;"> <form action="loginCheck.asp" method="post"> <table width=300 cellpadding=3 border=0 cellspacing=0 background=img/nav.gif> <tr> <td class=v12 colspan=2 bgcolor="E1692E"> <font color="ffffff">Please login with your user name and password</font></td></tr> <tr> <td class=v12>User name</td> <td class=v11> <input type="text" name="AdministratorUser" class="v11" style="Width:100"></td></tr> <tr> <td class=v12>Password</td> <td class=v11><input type="password" name="AdministratorPassword" class="v11" style="Width:100"></td></tr> <tr> <td class=v12>&nbsp;</td> <td class=v12><input type="submit" name="Submit" value="Log In" class="v11" style="Width:100" size="4" ></td></tr> </table> </form> </div> </body> </html>

8.3 Listing du fichier "logincheck.asp".

<%response.expires=0 login="" set rst=CreateObject("Adodb.recordset") sql="select * from Administrator" rst.open sql,Session("LinkToDatabase"),0,1 while not rst.eof if rst.fields("AdministratorUser")=request("AdministratorUser") and rst.fields("AdministratorPassword")=request("AdministratorPassword") then login="ok" end if rst.movenext wend rst.close set rst=nothing if login="ok" then %> <html> <body onLoad="javascript:document.form1.submit();"> <form method="post" name="form1" action="DLogin.asp"> <input type="hidden" name="LogIn" value="ok"> </form> <% else %> <html> <body> <script> alert('Your username and password combination are incorrect, please try again.') </script> <% end if %> </body> </html>

8.4 Listing du fichier "Coffee.asp".

<% response.expires=0 dag=request("viewday") maand=request("viewmonth") jaar=request("viewyear") datum=jaar & "," & maand & "," & dag %> <html> <head> <title>Catering List</title> </head> <link rel="stylesheet" href="verdana.asp"> <body> <table cellpadding=1 cellspacing=0 border=0> <tr><td class=vb20 colspan=8><font color=CC0000>Catering List</font></td></tr><tr> <td class=vb14 colspan=8><i><%=FormatDateTime(datum,vblongdate)%></i></td></tr> <tr><td colspan=8>&nbsp;</td></tr> </table> <table cellpadding=2 cellspacing=0 border=1 bordercolorlight="#CC6600" bordercolor="#CC6600" bordercolordark="#CC6600"> <tr> <td class=v12 width=100 align="center">Time</td> <td class=v12 width=100 align="center">Room name</td> <td class=v12 width=50 align="center">Participants</td> <td class=v12 width=60 align="center">Coffee</td> <td class=v12 width=60 align="center">Drinks</td> <td class=v12 width=60 align="center">Breakfast</td> <td class=v12 width=60 align="center">Lunch</td> <td class=v12 width=150>Comments</td> </tr> <tr> <td colspan=8></td> </tr> <% set rst=CreateObject("Adodb.Recordset") sql="Select * from Reservations INNER JOIN Rooms ON Reservations.Reservation_RoomId = Rooms.RoomID where ReservationDate=dateserial(" & jaar & "," & maand & "," & dag & ") order by ReservationStartTime" rst.open sql,Session("LinkToDatabase"),0,1

do while not rst.eof reservationName=rst.fields("Reservationname") reservationStartTime=rst.fields("reservationstarttime") reservationEndTime=rst.fields("reservationendtime") reservationtext=rst.fields("Reservationtext") reservationamount=rst.fields("Reservationamount") reservationCoffee=rst.fields("ReservationCoffee") reservationFris=rst.fields("ReservationFris") reservationBreakfast=rst.fields("ReservationBreakfast") reservationLunch=rst.fields("ReservationLunch") reservation_roomid=rst.fields("Reservation_roomid") roomnaam=rst.fields("roomNaam") tmp=int(reservationStartTime) Select case (reservationStartTime-tmp) Case 0 tmp=tmp & ":00" Case .25 tmp=tmp & ":15" Case .5 tmp=tmp & ":30" Case .75 tmp=tmp & ":45" Case Else tmp=tmp & ":00" End Select starttijd=tmp tmp=int(reservationEndTime) Select case (reservationEndTime-tmp) Case 0 tmp=tmp & ":00" Case .25 tmp=tmp & ":15" Case .5 tmp=tmp & ":30" Case .75 tmp=tmp & ":45" Case Else tmp=tmp & ":00" End Select eindtijd=tmp

%> <tr> <td class=v10 valign=top align="center"><%=starttijd%> - <%=eindtijd%>&nbsp;</td> <td class=v10 valign=top align="center"><%=RoomNaam%>&nbsp;</td> <td class=v10 valign=top align="center"><%=reservationamount %>&nbsp;</td> <td class=v10 valign=top align="center">&nbsp;<% if ReservationCoffee="yes" then%><img src="img/check.gif" width="15" height="15"><%end if%>&nbsp;</td> <td class=v10 valign=top align="center">&nbsp;<% if ReservationFris="yes" then%><img src="img/check.gif" width="15" height="15"><%end if%>&nbsp;</td> <td class=v10 valign=top align="center">&nbsp;<% if ReservationBreakfast="yes" then%><img src="img/check.gif" width="15" height="15"><%end if%>&nbsp;</td> <td class=v10 valign=top align="center">&nbsp;<% if ReservationLunch="yes" then%><img src="img/check.gif" width="15" height="15"><%end if%>&nbsp;</td> <td class=v10 valign=top ><%response.write replace(reservationtext,vbcrlf,"<BR>")%>&nbsp;</td> </tr> <% rst.movenext loop rst.close set rst=nothing %> </body> </html>

8.5 Listing du fichier: "res_form_save.asp".

<!--#include file="acces_base.inc" --> <% response.expires=0 msg="" DateOld="" dag=request("Dag") maand=request("Maand") jaar=request("Jaar") datum=Dateserial(request("Jaar"),request("maand"),request("dag")) if request("reservationId")="" then resid=0 else resid=request("reservationId") end if if not request("actie")="verwijder" then '' Form Check If request("ReservationName")="" then msg = msg & "Initials have to be filled in.<br>" end if If request("ReservationStarttime")*100 > request("ReservationEndTime")*100 then msg = msg & "The reservation must begin earlier than it ends.<br>" end if If request("ReservationEmail")="" then msg = msg & "Name must be be filled in.<br>" end if If not request("ReservationAmount")="" then set rst=CreateObject("Adodb.Recordset") sql="Select * from Rooms where roomid=" & request("Reservation_roomid") rst.open sql,Session("LinkToDatabase"),0,1 if not rst.eof then err.clear on error resume next If Cint(request("ReservationAmount"))>Cint(rst.fields("RoomMax")) then msg = msg & "The maximum of this room is " & rst.fields("RoomMax") & ".<br>"

end if end if rst.close set rst=nothing else msg = msg & "Number of people has not been filled in.<br>" end if if not err.Number=0 then msg=msg & "A mistake has ocurred. Please check the form.<br>" end if on error goto 0 '' check if start time en/of end time tussen de afspraken vallen set Check2=CreateObject("Adodb.Recordset") sql2="Select * from Reservations where reservation_roomid=" & request("reservation_roomId") & _ " AND ReservationDate=dateserial(" & jaar & "," & maand & "," & dag & ")" & _ " AND ReservationId <>" & resid & _ " AND ( ((ReservationStartTime*100 between " & Request("ReservationStartTime")*100 & " AND " & Request("ReservationEndTime")*100 & _ " and ReservationStartTime*100 <> " & Request("ReservationEndTime")*100 & _ ") OR (ReservationEndTime*100 between " & Request("ReservationStartTime")*100 & " AND " & Request("ReservationENdTime")*100 & _ " And ReservationEndTime*100 <> " & Request("ReservationStartTime")*100 & _ " )) " & _ " OR (( " & Request("ReservationStartTime")*100 & " between ReservationStartTime*100 and ReservationEndTime*100 " & _ " and " & Request("ReservationStartTime")*100 & " <> ReservationEndTime*100" & _ " ) OR (" & Request("ReservationEndTime")*100 & " between ReservationStartTime*100 and ReservationEndTime*100 " & _ " and " & Request("ReservationEndTime")*100 & " <> ReservationStartTime*100 " & _ " )) )" Check2.open sql2,Session("LinkToDatabase"),0,1 if not Check2.eof then msg=msg & "A reservation on this time and date has already been made.<br> Please remove this before making this reservation." end if Check2.close set Check2=nothing

9 Biblio
Web http://www.w3c.org http://fr.selfhtml.org/index.htm

Livresque Design Web: utiliser les standard CSS et XHTML de Jeffrey Zeldman EYROLLES ISBN: 2-212-11548-2