
par Stéphane Lambert
ous êtes encore
nombreux à ne pas être vraiment convaincus de la nécessité de passer
par la phase d'analyse avant de commencer réellement à coder.
Peut-être est-ce due à cette impression qu'a souvent l'autodidacte
(ou le débutant) que ce travail n'est pas réellement rentable. De
même, un client (ou un patron) peut avoir le sentiment de jauger
l'évolution d'un travail au nombre de lignes écrites, à la rapidité
ou les pages lui sont fournies, et donc à ce qu'il voit. Après être
revenus sur ces phénomènes très répandus, je vous présenterais une
introduction à une analyse beaucoup plus conséquente, analyse qui a
servie de base à un logiciel gérant la coupe du monde en France en
1998. Car quand les choses se compliquent un tout petit peu (et cela
arrive très très vite, et de plus en plus couramment), il n'est plus
question d'amateurisme sous peine de risquer, cette fois, le
naufrage total...
"Vite
! Pas Chère ! Et tout de suite."
Comme
tout un chacun, l'investisseur (client, directeur) raisonne très
souvent à court terme et exige rapidement des preuves que l'argent
qu'il investit est correctement utilisé, et que le temps de travail
qu'il paye est rentabilisé au maximum. Lui expliquer que quelques
jours ou quelques heures de réflexions sont parfois nécessaires pour
l'analyse peut le plonger dans un état suspicieux, avec parfois même
le sentiment d'être trompé sur le temps de travail facturé.
Pourtant, cette phase préliminaire représente les fondations même de
son projet : il vaut mieux qu'il ait son site quelques jours plus
tard mais que celui-ci soit correctement pensé et développé de
manière professionnelle. Ainsi, son bon fonctionnement, son
évolutivité et sa maintenance rentabiliseront largement son très
léger investissement.
"Analyser ? Réfléchir ?? Mais
pour quoi faire ???"
Un autre phénomène
très répandu est celui du "bidouilleur" : régulièrement autodidacte,
et généralement brouillon, il pense être capable de tout faire en
mettant lui-même la main à la pâte. Très souvent, il s'agit d'un
commercial persuadé qu'il pourra faire seul ce qui lui semble long
et cher sans raison. Dans un premier temps, il semblera y arriver, à
force de persévérances et d'interventions qui lui paraîtront être de
petites astuces très intelligentes et qu'il ajoutera ici et là, très
content de lui-même et de son résultat immédiat. Mais cela se
termine toujours de la même manière : son code et ses fichiers se
révelent être devenus si foullis et si incompréhensibles qu'il
finira par être incapable de faire fonctionner quoi que ce soit, et
devra se résoudre à appeler au secours. Seulement, il est souvent
trop tard, et la seule solution viable pour son site Web est de le
re-développer entièrement et correctement. Et là, ça coûte beaucoup
plus cher que quelques heures d'analyse ou les conseils d'un
professionnel.
Improviser : élimination
directe ?
Prenons un nouvel exemple un
plus complexe : en 1998, a eu lieu en France la coupe du monde de
Football. De très nombreux sites Web ont alors entamé des
développements spécifiques, afin de présenter un certain nombre
d'informations concernant la compétition aux internautes. Leur
besoin a tout d'abord été de fournir à leurs journalistes des outils
rédactionnels afin de leur permettre d'afficher en ligne les
articles concernant la compétition. La plupart de ces sites étant
déjà dotés d'interfaces de travail pour les autres secteurs
d'actualités, cette tache s'est généralement révélée assez simple.
Mais, pour ce qui concernait le stockage et la présentation des
résultats et des statistiques, ce fut une tout autre histoire...
Extraits d'un petit briefing de l'équipe technique :
"Ecoute, le webmaster, vient voir : Là, il y a la coupe
du monde qui commence la semaine prochaine. On va présenter les
scores des matchs, et deux trois petits classements faciles. Tu nous
fais un machin hyper-simple pour qu'on puisse faire un max
d'audience avec tous les footeux. Tu vois, un petit programme où là,
on rentre les buts et les cartons, et quand on clique ici, sur le
site, on voit tout comme il faut. Comme ça, les journalistes, ils
marquent dans une petite fenêtre que le match a eu lieu ici, avec
les joueurs qui jouent, les buteurs qui marquent, les remplacés qui
sortent et le type qui arbitre. Comme dans le journal, quoi.... Toi,
tu leur fais gentiment une moulinette pour stocker tout ça et tout
afficher tranquillement sur le site quand le surfeur il le demande.
OK ? Ca va ? Tu vois, un truc comme ça, tranquille..."
Eh ben c'était pas gagné...
Tacle
en retard : carton Rouge !
Je ne sais pas si vous
vous souvenez du spectacle alors offert par certains des sites Web
concernés : joueurs ayant marqué 327 fois en 4 matchs, Barthez dans
l'équipe du Brésil, Zidane finaliste en totalisant 23 minutes de
jeux sur le terrain, résultats farfelus, quand résultats tout court
il y eut. Car bien souvent, le développement se résuma en dernier
ressort à afficher en catastrophe des pages statiques avec les
feuilles de match, les classements et les résultats écrits
directement en dur, dans des pages HTML fixes. Il y eu même des
sites très connus (qu'on ne citera pas) qui furent totalement
incapables de présenter le moindre résultat avant la fin de
l'épreuve !
Pour ceux qui seraient interressés, j'ai
concocté une petite analyse sur cette épreuve. Bien évidemment,
selon les informations que l'on voudra stocker ou présenter,
certaines modifications peuvent être apportées. Il ne faut pas
perdre de vue que dans ce type d'analyse, il n'y a pas UNE mais bien
souvent plusieurs solutions. Tout dépend de ce que l'on veut
réellement faire. Néanmoins, cela devrait tout de même ressembler à
cela :
Cliquez sur les schémas pour les agrandir
:
Bien
gérer les individualités
Un petit
mot sur ce MCD et ce MPD :
- On remarque tout d'abord les cardinalités (1,1) mises
entre parenthèses : elles décrivent ce que l'on appelle des
entités dépendantes. En effet, une Equipe est liée à son
Groupe, de même qu'un But et un TirsAuBut ne
peuvent exister sans le Match lors duquel ils ont été
marqués. Cela s'appelle un identifiant relatif. La conséquence
d'un identifiant relatif est que la table générée par l'entité a
comme double clé primaire son propre identifiant ainsi que
l'indentifiant de l'entité dont elle dépend.
- Le champ NBPOINTS de la table EQUIPE : ce
renseignement pourrait être retrouvé par une requête appropriée
prenant en compte les résultats des matchs joués précédemments.
Néanmoins, le nombre de points pouvant être modifié sur tapis
vert, il est judicieux de prévoir qu'il puisse ne pas correspondre
aux résultats précédents. Il ne s'agit donc pas d'une redondance,
un facteur externe pouvant intervenir et modifier sa valeur. Cela
implique tout de même que le développeur devra prévoir à la fois
de le mettre à jour lors de la saisie des résultats (par
procédures stockées ou par une fonction de son script), et une
interface permettant d'y accéder et d'y écrire directement.
- le champ CODEPROLONGATION de la table MATCH
sert à savoir si un match a eu ou non des prolongations,
renseignements non indiqués par tous les score.
- Il y a une double relation 1,1 entre les entités Equipe et Pays. Normalement, cela voudrait dire que Pays est un argument de Equipe, et ne devrait pas devenir une table. Mais ici, Pays sert aussi pour les Arbitres, et est donc une entité reliée à Arbitre par une relation (1,1)-(0,n). Cette légère disgression se trouve donc justifiée par la liaison Pays-Arbitre.
Cela paraît compliqué ? Pourtant, il n'y a que 21 tables. Certains systèmes d'informations sont bien plus complexes que cela, il n'est pas rare qu'une boutique complète repose sur une base de données de près de 70 tables. Mais déjà, là, il n'est plus question d'improviser et de créer ses tables au hasard, sous peine de se retrouver coincé et d'avoir rapidement de très gros soucis. Avec un poil d'expérience, une telle analyse peut être réalisée en quelques jours. Comme d'habitude, si elle correspond effectivement au besoin du client, le développement se résumera ensuite à une interface d'administration pour remplir correctement la base, puis à un moteur d'affichage à base de requêtes pour en afficher le contenu.
Ne pas
trop exagérer
Il conviendra tout de même
de ne pas tomber dans l'excès inverse : l'analyse est là pour nous
faire gagner du temps, pas pour nous en faire perdre. Merise, Gare
Yourdon et les autres sont des méthodes très complètes qui peuvent
néanmoins se révéler excessivement lourdes et contraignantes. Il
n'est pas question ici d'utiliser au pied de la lettre ces procédés
dans leur intégralité. Mais les techniques du Client/Serveur sont en
train d'arriver sur le Web, les sites dynamiques se compliquent et
se professionalisent. Et la méthode que je vous propose dans mes
articles est simple, toujours vrai, rapide, efficace, et vous rendra
donc de fiers services.
A bientôt...
<< Lire la 4ème partie |
Stéphane Lambert http://www.vediovis.fr/
Spécialisé dans le
développement Web, Stéphane LAMBERT
a fondé VEDIOVIS PRODUCTIONS
en Mai 2000.
Son expérience couvre essentiellement les sites à
fortes audiences,
institutionnels ou
audiovisuels.
Tous droits réservés - Reproduction même partielle interdite sans autorisation préalable

Stéphane LAMBERT- vediovis

Tel : (+66) 899 33 6088 - (+33) 6 16 21 09 60
© 2017 Vediovis Productions