Le bruit de la machine à écrire doit plaire aux plantes… / Elaboration du cahier des charges et du MCD

Me voici donc avec une meilleure idée de l’univers dans lequel nous nous aventurons. J’ai beau ne pas encore être bien à l’aise avec les concepts AJAX, j’en sais désormais assez pour savoir comment doit s’orienter mon idée, en connaissant mieux les limites techniques et les possibilités offertes par le web 2.0.

Repenser une idée avec des frontières n’est pas chose aisée.
Cela signifie ne plus donner libre cours à ses délires, mais inclure dans chaque aspect de l’idée, des frontières rigides, en attendant des jours où nos propres capacités ou celles des machines nous permettront d’évoluer encore et de réouvrir les vannes à l’imagination.

Avec mon associée, on devait donc commencer à poser notre concept en terme concret.
Du « On pourrait faire cela » dans le vent, il fallait passer à « On peut faire cela en intégrant telle ou telle étape, connue, testée et validée ».

Nous voici donc revenu au papier, pour réaliser une application web 2.0.
NB: à ceux qui continueraient à me lire sans savoir, je rappelle que le terme « Web 2.0 » n’est qu’une terminologie qui date de 2004, et qui évoque l’apport des regroupements sociaux sur la toile ainsi que des technologies issues d’AJAX qui ont permis une intercommunicativité accrue dans ces réseaux – http://fr.wikipedia.org/wiki/Web_2.0

Etape 1: Avoir une visibilité sur ce que l’on peut désormais mettre en oeuvre par rapport à l’idée de départ, au vu des technologies envisageables à notre niveau.

Etape 2: En déduire le déroulement de l’application. C’est à dire, pour le web, l’écran d’accueil, suivi du cheminement à travers un site qui constitue une suite de fonctionnalités par écran. Nous appellerons cela le schéma de cinématique d’écrans.

Etape 3: Expliciter pour chaque écran l’ensemble des fonctionnalités, en définissant chaque donnée à manipuler, chaque traitement à lancer en client ou en serveur.
Appelons cela le cahier des charges fonctionnel.

Etape 4: En déduire le Modèle Conceptuel de Données.

Nous voyons donc bien que nous sommes bien éloignés d’un site « standard », web 1.0.
Ces 4 étapes ressemblent davantage à la mise en place d’une application métier en client lourd, qu’à un site web qui n’a – je le précise ici – rien de marchand pour le moment.

L‘étape 1 est plus ou moins ce que l’on a fait jusqu’ici: chercher, tester, vérifier et conclure.
Les étapes 2 et 3 furent liées. Et le schéma de cinématique d’écrans évoluait avec l’écriture du cahier des charges: l’une et l’autre étape se répondent et se coordonnent.

Voici à quoi ressemble actuellement le coeur du schéma de cinématique d’écrans:

Cela représente à peu près 30 écrans de gestion différents, pour une quarantaine de page dans le cahier des charges. Cela englobe le système central « visible », mais notre projet met en oeuvre un certain nombre de processus invisibles que nous n’avons, à ce jour, pas encore explicitement décrits.

Au bout d’un mois et demi d’écriture, nous avions quelque chose de cohérent, sur lequel s’appuyer réellement pour parler entre nous, montrer du doigt, créer les écrans et les programmes qui les liaient.

En parallèle de ce travail, la recherche sur les technos se poursuivaient sur certaines parties, laissées un peu de côté jusqu’ici, mais que nos avancées nous permettaient de faire progresser à ce moment: il s’agissait des framework AJAX, qui constituent de belles possibilités à mettre en oeuvre dans des applis web 2.0, tout en conservant la maîtrise du flux de données échangé.

Je vous ferais bien un exposé sur ces framework (http://fr.wikipedia.org/wiki/Framework), mais d’une part, je ne ferais que plaggier totalement ceux qui en parlent bien mieux que moi sur www.developpez.com, où j’ai pratiquement tout appris sur le sujet, et d’autre part, cela m’emmènerait trop loin de mon sujet de blog, alors même que je maîtrise mal ce que je vais faire avec.

Pour votre information, je vous suggère ces liens:

Une discussion dans un forum de Developpez, très instructives aussi sur des personnes ayant déjà testé certains framework.

La propre liste de Developpez sur les framework AJAX.

De mon côté, mes recherches et mes besoins me conduisent à penser que Script.Aculo.Us sera notre framework AJAX probable (http://script.aculo.us/).
Mais cela bouge tant en ce domaine, qu’il faut se tenir sans cesse au courant des avancées et des apports des uns et des autres. Sur beaucoup de forums, j’ai lu que untel utilisait tel framework pour ceci, tel autre pour cela, encore un autre pour cela…

Or, il faut savoir qu’utiliser un framework AJAX signifie envoyer le code de celui-ci au client – c’est du javascript, il étend les capacités du DOM en amenant des fonctionnalités inédites – et donc faire transiter pas mal d’octets…
Donc s’il y a beaucoup de framework à faire passer, vous allourdissez votre page…

Pas facile de faire un savant mélange, surtout de tête… Et il n’existe aucun moyen de « simuler », à priori, le coût de votre choix, pour le site. Il faut donc tout coder d’abord pour s’apercevoir qu’il va falloir passer autrepart quand vous appelez votre page (souvenez-vous mon expérience en Full php…)

Idée: Celui qui créera un logiciel capable de prévoir le coût machine (processeur ,ram, réseau) du besoin utilisateur et qui serait à même de le « tuner » (ça pour le client avec un peu de ce framework, et ça pour le serveur avec ce code php optimisé…), est un homme riche – je précise, ce n’est pas notre idée, on est pas du tout assez balèze pour cela

Sur ces mots, je vous laisse pour passer en août où… Il va passer peu de choses, et pour cause…