Projet : Système de Gestion de Pannes.

 

I. Etude préliminaire.

I.a Capture des besoins fonctionnels.

Un établissement scolaire possède une vingtaine de salles informatiques. Ces salles sont occupées par des lycéens pour leurs formations. Ces salles accueillent différentes classes sur des périodes fixes de la semaine. Différentes pannes surviennent tant au niveau matériel que logiciel. Actuellement une panne est signalée par l'enseignant présent dans la salle, sur un papier préimprimé et remis à l'administateur. Celui-ci a la responsabilité de traiter la panne. Le nouveau système à mettre en place doit permettre d'effectuer ces traitements en intranet et de réaliser un suivi des interventions, afin de créer une mémoire des interventions "types" consultable par d'éventuels nouveaux administrateurs.

I.b Capture des besoins techniques.

Le parc informatique n'est pas homogène et évolue rapidement, le système à mettre en place devra tenir compte de cette contrainte.

La partie persistante de l'application devra être indépendante du SGBD(R).

Le choix d'architecture intègrera des produits Open Source ( Apache/PHP)

Il n'y pas de contrainte forte en terme de temps de réponse : choix du pattern "client léger" - toute la logique métier sera assurée par le serveur -, le client sera réduit à un interpréteur HTML, sans script. embarqués. Choix d'une architecture 3 tiers

La modularité nécessaire impose une programmation objet. La modélisation utilisera le langage UML.

II Analyse.

II.a Analyse fonctionnelle.

Chaque professeur peut saisir une panne concernant un ordinateur, dans sa salle ou tout autre salle. Un mot de passe propre à chaque enseignant sécurise l'accès. L'administrateur assure la maintenance; il devra se tenir régulièrement informé de l'état du parc informatique et saisir les différentes interventions sur les pannes. Il devra pouvoir visualiser différents états statistiques sur les pannes. Les pages concernant les enseignants et l'administration devront être sécurisées.

L'application s'appuiera sur ces trois cas d'utilisation fonctionnels.

II.a.1 Cas d'utilisation : saisie d'une panne.

Description textuelle:

Portée : SGP

Niveau : statégique

Acteur principal : enseignant

Préconditions : l'enseignant peut se loguer au système

Déclencheurs : découverte d'une panne

Scénario nominal :

1.L'enseignant se logue à l'application

2.Le système vérifie le mot de passe

3.L'enseignant sélectionne sa salle

4.Le système retourne l'état des ordinateurs de la salle

5. L'enseignant sélectionne l'ordinateur concerné.

5.L'enseignant remplit un formulaire de panne

6.Le système valide et enregistre la panne

Extensions :

2.1 Le système ne valide pas les informations uid/pwd.Retour à 2

5.1 la panne a déjà été signalée. Fin

5.2 les informations saisies sur la panne sont insuffisantes

5.2.1 le système demande des précisions sur la panne

Fréquences : à chaque panne

II.a.2 Cas d'utilisation : saisie d'une intervention.

Portée : SGP

Niveau : statégique

Acteur principal : administrateur

Préconditions : l'administrateur peut se loguer au système

Déclencheurs : réalisation d'une intervention

Scénario nominal :

1. L'administrateur se logue à l'application

2. Le système vérifie le mot de passe

3.L'administrateur sélectionne une salle

4.Le système retourne l'état des ordinateurs de la salle et les pannes éventuelles.

5. L'administrateur sélectionne une pane.

6.L'administrateur remplit un formulaire d'intervention pour cette panne.

7.Le système valide et enregistre l'ntervention.

extensions.

2.1 Le système ne valide pas les informations uid/pwd.Retour à 2

5.2 les informations saisies sur l'intervention sont insuffisantes

5.2.1 le système demande des précisions sur l'intervention

II.a.3 Cas d'utilisation : visualiser les interventions.

Portée : SGP

Niveau : utilisateur

Acteur principal : administrateur

Préconditions : l'administrateur peut se loguer au système

Déclencheurs : réalisation d'une intervention

Scénario nominal :

1. L'administrateur se logue à l'application

2. Le système vérifie le mot de passe

3.L'administrateur sélectionne une statistique sur l'état des pannes ou des interventions..

4.Le système retourne l'état concerné.

 

II.a.4 Diagramme de cas d'utilisations.

Plusieurs séquences des cas d'utilisation sont communes: le login et la sélection de l'ordinateur. Nous pouvons mettre en évidence des cas d'utilisation "include".

II.b Analyse des données persistantes.

Nous utiliserons un modèle entité association.

Remarques : chaque intervention dépend d'une panne particulière. le type de panne précise si la panne est métérielle ou logicielle. Le degré d'urgence est précisée lors de la panne, ce degré pourra être modifié par l'admistrateur et indiquer par exemple que la panne est réparée. L'admistrateur est un enseignant

La base de données sera installée sur Access

Nous utiliserons le modèle général MVC - modèle, vue, controleur - afin de séparer les données, la logique applicative et la présentation.

 

UML fournit trois stéréotypes de classe indiquant ces fonctionalités :

- classe <<boundery>> : limite du système.

- classe <<entity>> : classe du domaine, souvent persistantes.

- classe <<interface>> : assure la cohérence entre les deux premières.

La mise en oeuvre systématique de ce modèle dans les applications WEB est parfois délicate dans la mesure où il est difficile - et lourd - de séparer trop mécaniquement la vue du controleur, cf plus loin.

III Eléments de conception.

Le choix de mise en oeuvre se portera sur un langage de script : PHP. Sa fiaibilité en fait aujourd'hui un outil très prisé.

La conception doit permettre de séparer très clairement les responsabilités des pages.

L'analyse préalable des besoins techniques a mis l'accent sur l'indépendance entre la logique applicative et la base de données. Aussi, un "package" de classes PHP servira de "facade" entre les tables relationnelles et la logique applicative.

L'avantage de ce modèle est évident : les pages php frontières ou contrôleurs ne contiendront aucune fonction d'accès aux données. Toute la logique applicative utilisera les trois classes techniques. Toutes modification de la base cible se traduira par un remplacement du package FaçadeBase. Le code applicatif fonctionnera sur ODBC ( notre choix ) ou en natif sur Mysql ( par exemple )

Les vues <<boundary>> seront assurées par des pages en HTML ou PHP. Des classes/pages <<contrôleur>> assureront la cohérence entre les vues et le modèle.

Décrivons les couches logicielle de l'application :

Présentation
HTML/PHP
Logique applicative
PHP
Mapping
PHP/package FacadeBase
Sgbd
Access

 

A titre informatif, nous reproduisons un document paru dans "Développeur Référence" décrivant l'architecture à 5 couches.

 

III.b Mise en oeuvre du modèle de conception.

Si l'on applique ce modèle au cas d'utilisation "Saisir uid/pwd", le diagramme suivant montre les liens entre les classes et/ou pages.

Ce modèle sera repris pour tous les cas d'utilisation nécessitant une validation de saisie ou un enregistrement dans les tables.

Pour les cas d'utilisation présentant une simple vue des données, le modèle sera réduit : le code contrôleur sera intégré dans la page php de la vue :

 

III.c Description du package FaçadeBase.

Trois classes sont proposées:

III.d Diagramme des pages.

Remarque : les tables n'apparaissent pas sur ce diagramme, elles sont liées uniquement au package FaçadeBase.

Les pages "Interface utilisateur", <<boundary>> sont intitulées iu, les pages contrôleurs sont intitulées ctr.

III.e Maquètes logiques des pages.

Cette page permet de diriger l'administrateur vers un menu personnel, l'enseignant vers la sélection d'un ordinateur; toute erreur de login redirige vers cette page.Chaque page accédée vérifiera la nature de la connexion ( administrateur ou enseignant )

Un lien sur chaque ordinateur va ouvrir la page de pannes:

 

Cette page propose des liens sur les pannes, et permet d'enregistrer une intervention relative à la panne choisie:

 

L'administrateur peu modifier l'urgence de la panne.

 

 



Cette page met en relation les pannes et les interventions

IV Implémentation.

IV .A Eléments de programmation en mode déconnecté.

Gestion des variables

Les variables construites dans une page ne sont récupérables que par la page - ou le programme - qui est indiquée dans le paramètre action d'un formulaire. Plusieurs techniques existent si l'on désire conserver ces variables.

Dans le projet SGP, nous utiliserons la première et la dernière solution.

Par exemple une variable de type session sera utilisée pour identifier le type d'utilisateur : enseignant ou administrateur. Cette variable "suivra" l'internaute et sera testée au début de chaque page.

Première soumission d'un formulaire.

Il est parfois nécessaire de savoir si un formulaire est soumis une première ou une deuxième fois; pour le tester il est préférable de faire passer une variable dans l'url plutôt que de tester des champs vides (indépendance entre un formulaire et son contrôle)

exemple:

Dans le formulaire login.iu.php : if ($incorrect) print ("erreur de login ");

Dans la page de contrôle : header("location:login.iu.php?incorrect=1");

Les sessions

Chaque visiteur se voit attribué un identifiant de session, un fichier est créer sur le serveur - par défaut dans le répertoire tmp de Apache - ayant comme nom cet identifiant. Il sera possible par la suite de "suivre" le visiteur et de déclarer des variables persistantes de type session. PHP utilise deux techniques pour "propager" cet identifiant chez le visiteur: un cookie ou un passage transparent dans l'URL: on peut désactiver l'utilisation de cookie dans le fichier php.ini.

Si le fichier php.ini contient l'option auto_start = 1, chaque visite entraine la réation d'une session ( détruire par session_destroy()). Si ce n'est pas le cas il faudra dans le code php commencer par l'instruction session_start().

Pour déclarer une variable de type session, on écrit :

session_register("numEnseignant");

Les variables déclarés comme des variables sessions - enregistrées par le serveur dans le ficheir de session -seront accessibles directement dans toutes les pages.

Il y a deux façons d'utiliser des variables de session:

Différentes fonctions sont disponibles permettant de supprimer ces variables, mettre fin à la session etc...cf doc.

Redirection vers une page.

L'utilisation d'une fonction header(location : page.php) permettra de rediriger vers les pages concernées; cette fonction doit figurer avant toute génération de caractères - avant tout code html en particulier -. Cette contrainte est due à la nature même de la fonction header qui intervient au niveau du protocole HTTP et va générer l'en-tête de requête, et donc si du texte est généré au préalable, une en-tête propre va être générée contradictoire avec celle générée par la fonction header.

Exemple: validation des saisies du login

if($req->nbLignes()==1){ //l'enseignant a été trouvé

$HTTP_SESSION_VARS["numEnseignant"]=$req->champ(1);

if($HTTP_SESSION_VARS["numEnseignant"]==0){ // c'est l'administrateur

$HTTP_SESSION_VARS["valide"] = 2;

header("location:menuadmin.iu.php");

}

else{

$HTTP_SESSION_VARS["valide"]=1;

header("location:selectordi.iu.php");

}

}

else

header("location:login.iu.php?incorrect=1");

Une classe technique : document

Afin de limiter l'écriture de balises HTML, une classe document est utilisée

IV .B Code des pages.

...Me contacter