fsac Universitaire 2010-2011 Dpartement Math-Info

Anne

Atelier Pratique En dveloppement Web/J2EE

Enonc 1. Etude de cas : Gestion d'une base d'articles sur le web Une socit dsire grer les articles qu'il vend en magasin travers son site web. La socit a un compte chez un fournisseur d'accs Internet, fournisseur autorisant ses clients installer des scripts JSP/Servlet dans leurs dossiers personnels. Ceci leur permet de crer des sites web dynamiques. Par ailleurs, ces mmes clients disposent d'un compte MySQL leur permettant de crer des tables pouvant servir des donnes leurs scripts. Ainsi la socit a un compte MySQL ayant pour login admarticles et mot de passe mdparticles. Il possde une base dbarticles sur laquelle il a tous les droits. Elle a donc les lments suffisants pour mettre sa gestion d'articles sur le web. Notre client fait la maquette suivante comme interface web daccueil :

Il y aurait deux sortes d'utilisateurs : Des administrateurs qui pourraient tout faire sur la table des articles (ajouter, modifier, supprimer, consulter, ...). Ceux-l pourront utiliser tous les lments du menu ci-dessus. En particulier, ils pourront mettre toute requte SQL via l'option [Requte SQL]. Les utilisateurs normaux (pas administrateurs) qui auraient des droits restreints : droits d'ajouter, de modifier, de supprimer, de consulter. Ils peuvent n'avoir que certains de ces droits, le seul droit de consultation par exemple. 1

fsac Universitaire 2010-2011 Dpartement Math-Info

Anne

Du fait qu'il y a divers types d'utilisateurs de la base n'ayant pas les mmes droits, il y a ncessit d'une authentification. C'est pourquoi la page d'accueil commence avec celle-ci. Pour savoir qui est qui, et qui a le droit de faire quoi, deux tables USERS et DROITS seront utilises. La table USERS aurait la structure suivante :

Login : login de l'utilisateur l'identifiant de faon unique. Ce champ est cl primaire de la table. Mdp : le mot de passse de lutilisateur Admin : le caractre 'y' (yes) si l'utilisateur est administrateur, sinon le caractre 'n' (no). La table DROITS prcise les droits qu'ont les utilisateurs non administrateurs prsents dans la table USERS. Sa structure est la suivante :

Login : login de l'utilisateur l'identifiant de faon unique. Ce champ est cl trangre de la table DROITS et rfrence la colonne login de la table USERS. table : le nom de la table sur laquelle l'utilisateur a des droits. Ajouter : le caractre 'y' (yes) si l'utilisateur a un droit d'ajout sur la table, sinon le caractre 'n' (no). modifier : droit de modifier : 'y' ou 'n' supprimer : droit de supprimer : 'y' ou 'n' consulter : droit de consulter : 'y' ou 'n' Le contenu de la table pourrait tre le suivant :

fsac Universitaire 2010-2011 Dpartement Math-Info

Anne

Remarques : Un utilisateur U se trouvant dans la table USERS et absent de la table DROITS n'a aucun droit. Dans notre exemple, les utilisateurs n'auront accs qu' une seule table, la table ARTICLES. Mais notre commerant, prvoyant, a nanmoins ajout le champ table la structure de la table DROITS afin de se donner la possibilit d'ajouter ultrieurement de nouvelles tables son application. Pourquoi grer des droits dans nos propres tables alors qu'on fait l'hypothse qu'on utilisera une base MySQL capable elle mme (et mieux que nous) de grer ces droits dans ses propres tables ? Simplement parce que notre commerant n'a pas les droits d'administration sur la base MySQL qui lui permettraient de crer des utilisateurs et de leur donner des droits. N'oublions pas en effet que la base MySQL est hberge chez un fournisseur d'accs et que le commerant n'est qu'un simple utilisateur de celle-ci sans aucun droit d'administration (heureusement). Il possde cependant tous les droits sur une base appele dbarticles laquelle il accde pour le moment avec le login admarticles et le mot de passe mdparticles. C'est dans cette base que prennent place toutes les tables de l'application. La table ARTICLES rassemble les informations sur les articles vendus par le commerant. Sa structure est la suivante :

code : code de l'article - cl primaire de la table - 4 caractres exactement nom : nom de l'article prix : son prix stockActuel : le niveau actuel de son stock

fsac Universitaire 2010-2011 Dpartement Math-Info

Anne

stockMinimum : le niveau au-dessous duquel, une commande de rapprovisionnement doit tre faite. Son contenu utilis dans un premier temps comme test pourrait tre le suivant :

3. Les contraintes projets Le commerant migre ici une application ACCESS locale en une application Web. Il ne sait ce que deviendra celle-ci et comment elle voluera. Il voudrait cependant que la nouvelle application soit facile utiliser et volutive. C'est pour cette raison que son conseiller informatique a imagin pour lui, lors de la conception des tables, qu'il pouvait y avoir : divers utilisateurs avec diffrents droits : cela permettra au commerant de dlguer certaines tches d'autres personnes sans pour autant leur donner des droits d'administration dans le futur d'autres tables que la table ARTICLES Le mme conseiller fait d'autres propositions : il sait que dans le dveloppement logiciel, il faut sparer nettement les couches prsentation et les couches traitement. L'architecture d'une application web est souvent la suivante :

L'interface utilisateur est ici un navigateur web mais cela pourrait tre galement une application autonome qui via le rseau enverrait des requtes HTTP au service web et mettrait en forme les rsultats que celuici lui envoie. La logique applicative est constitue des scripts traitant les demandes de l'utilisateur, ici des scripts PHP. La source de donnes est souvent une base de donnes mais cela peut tre aussi un annuaire LDAP ou un service web distant. Le dveloppeur a intrt maintenir une 4

fsac Universitaire 2010-2011 Dpartement Math-Info

Anne

grande indpendance entre ces trois entits afin que si l'une d'elles change, les deux autres n'aient pas changer ou peu. Le conseiller informatique du commerant fait alors les propositions suivantes : On mettra la logique mtier de l'application dans une classe. Ainsi le bloc [Logique applicative] ci-dessus sera constitu des lments suivants :

Dans le bloc [Logique Applicative], on pourra distinguer : le bloc [IE=Interface d'Entre] qui est la porte d'entre de l'application. Elle est la mme quelque soit le type de client. le bloc [Classes mtier] qui regroupe des classes ncessaires la logique de l'application. Elles sont indpendantes du client. le bloc des gnrateurs des pages rponse [IS1 IS2 ... IS=Interface de Sortie]. Chaque gnrateur est charg de mettre en forme les rsultats fournis par la logique applicative pour un type de client donn : code HTML pour un navigateur ou un tlphone WAP, code XML pour une application autonome, ... Ce modle assure une bonne indpendance vis vis des clients. Que le client change ou qu'on veuille faire voluer sa faon de prsenter les rsultats, ce sont les gnrateurs de sortie [IS] qu'il faudra crer ou adapter. Dans une application web, l'indpendance entre la couche prsentation et la couche traitement peut tre amliore par l'utilisation de feuilles de style. Celles-ci gouvernent la prsentation d'une page Web au sein d'un navigateur. Pour changer cette prsentation, il suffit de changer la feuille de style associe. Il n'y a pas toucher la logique de traitement. On utilisera donc ici une feuille de style.

fsac Universitaire 2010-2011 Dpartement Math-Info

Anne

Dans le diagramme ci-dessus, c'est la classe mtier qui fera l'interface avec la source de donnes. Par hypothse, cette source est ici une base MySQL. Afin de permettre une volution vers une autre base de donnes, on utilisera la bibliothque PEAR qui offre des classes d'accs aux bases de donnes indpendantes du type rel de celles-ci. Ainsi si notre commerant s'enrichit au point de pouvoir installer un serveur web IIS de Microsoft dans son entreprise, il pourra remplacer la base MySQL par SQL Server sans avoir (ou trs peu) changer la classe mtier.