PRESENTATION

CodeWorker ("http://www.codeworker.org") est n du constat qu'un grand nombre de tches de dveloppement gagneraient  tre
automatises :
	- application de "coding patterns" sur le code source,
	- correction  appliquer sur l'ensemble des objets de l'application,
	- tenir une documentation  jour sans effort et sans dcalage avec le dveloppement,
	- avoir l'ide d'une nouvelle fonctionnalit (modle de conception)  appliquer et 
		personnaliser sur l'ensemble des objets mtier (que chacun sache s'crire sous XML ou
		que chacun soit capable de vrifier ses contraintes de validit par exemple),
	- n'avoir  retoucher que le code mtier lorsque les membres d'un objet sont modifis,
	- gnrer des crans de saisie automatiquement,
	- gnrer une page HTML qui retrace intelligemment toutes les modifications faites sur
		une application et portes dans un fichier "changes.log" (pour les dveloppeurs les
		plus srieux, qui doivent maintenir une Release Notes  chaque livraison d'une nouvelle
		version),
	- transformer des donnes crites dans un certain format, sous un autre format, et qu'il
		n'existe pas de traducteurs sur le march,
	- interroger le coeur de l'application  partir d'un browser,
	- ... tout ce qui est rptitif ou fastidieux  maintenir en cas de modification,

Ces tches peuvent paratre amusantes  implmenter une fois, mais pas  maintenir ou 
reproduire manuellement sur l'ensemble d'une application. Elles demandent de plus un nombre
plus important de dveloppeurs pour les mener  bien, qui introduiront forcment un lot
consquent de bugs. Et ce, d'autant plus que ce travail n'est gure exaltant.
Le pire est de grer l'impact d'une modification, faite sur les attributs d'un objet
par exemple, dans l'ensemble des fonctionnalits ralises (ne pas oublier de modifier l'cran
de saisie, l'criture en XML, les contraintes de validit, ...). Un ingnieur occup  ces
tches est sous-employ et a moins de temps  consacrer  la conception et aux fonctionnalits
mtier. De plus, il perdra toujours trop de temps  dbugger les erreurs qu'il aura commises
(le pire tant de revenir sur une erreur de conception, puisque cela implique des
transformations en profondeur).

CodeWorker est un outil qui permet de pallier tous les inconvnients cits ci-dessus qui, on
l'a vu, affaiblissent considrablement la robustesse et la ractivit. CodeWorker se prsente
sous la forme d'un langage de script qui apporte toutes les facilits pour gnrer du texte.
La nature du texte gnr est totalement libre. Il peut s'agir :
	- de code source, crit en JAVA, en C++ ou en n'importe quel autre langage de programmation,
	- de documentation, crit en HTML, en LaTeX ou en n'importe quel langage de traitement de
		texte qui offre une reprsentation non binaire du document (et qui dispose du moyen
		d'introduire des commentaires),
	- de procdures stockes d'insertion/suppression d'objets dans une base de donnes
		relationnelle (ce qui implique notamment la prise en charge du mapping objet/relationnel),
	- d'un fichier d'entre destin  une application, par exemple :
		- un fichier XML destin  ANT (outil de makefile pour JAVA),
		- description des noeuds d'un graphe complexe pour "GraphViz" (outil qui permet de
			dessiner une grande varit de graphes, pour la modlisation, le workflow,
			la mdecine, la chimie, les statistiques, ...),
Ces exemples ne sont l qu' titre illustratif, et sont loin d'tre exhaustifs. La limite est
fixe par l'imagination ou les capacits de l'architecte d'application, du concepteur et du
dveloppeur.

Disposer d'un bon outil de gnration de code n'a pas de sens si l'on ne sait pas acqurir la
reprsentation conceptuelle de ce qu'il faut gnrer. Il peut s'agir :
	- d'une modlisation UML,
	- d'une modlisation Merise,
	- du schma d'une base de donnes crit en SQL,
	- de la description formelle d'changes de donnes/messages entre processus
	- du descripteur de dploiement d'une architecture J2EE-EJB,
L encore, la liste est loin d'tre exhausive, et ne se limite qu' tout ce qui peut se dcrire
dans un fichier texte dont la syntaxe est connue et exploitable par une machine. En fait, cela
n'exclut que les documents crits en langage naturel (franais, anglais, ...), dont le contenu
est, par nature, non formalis.

On dcouvrira au fur et  mesure en quoi cet outil rpond rellement au besoin de fiabilit,
robustesse, ractivit et capitalisation de la connaissance qui se fait sentir aujourd'hui sur
les moyens et grands projets. Et ce, indpendamment d'un quelconque clocher,  savoir JAVA,
Lotus Notes, Oracle, VB ou C++ et d'autres encore.


ACQUISITION DE LA CONNAISSANCE

Le frein  cette dmarche d'acquisition du fichier de modlisation sont la lecture de sa syntaxe
et l'extraction de la connaissance. C'est ce qui a justifi l'expansion de XML ces dernires
annes. Faisons une petite digression sur XML. En soi, XML n'a rien d'exceptionnel ou de
nouveau (tous ses concepts sont issus de son grand pre SGML) et beaucoup, suivant en cela le
courant du moment, lui ont donn une importance qu'il ne mritait pas. Cependant, il dispose
de trois atouts majeurs :
	- son rle de hirarchisation de la connaissance, de n'importe quelle connaissance,
	- sa comprhension  la fois par l'tre humain et par la machine,
	- l'invariance de sa syntaxe, qui permet d'crire un 'lecteur' unique pour chaque langage
		de programmation ('lecteur': outil qui reconnait la syntaxe du flux de donnes, un
		fichier le plus souvent)
Ces trois atouts lui permettent de reprsenter n'importe quelle information sous une forme
structure. Cette forme structure se prsentera sous la forme d'un graphe dans la mmoire
de l'application qui le lit (via le 'lecteur'). Cette opration est appele le 'parsing' et
consiste, au cours de la lecture,  alimenter un graphe (dit 'de parsing') avec la connaissance
extraite du flux de donnes XML. Tout langage de programmation dispose maintenant d'une
librairie capable de parser n'importe quel fichier XML.

Pourquoi cette digression sur XML? Parce que c'est un moyen connu de tous d'acqurir de la
connaissance, dj mise en forme pour la gnration de code : il suffirait de piocher
l'information  gnrer dans le graphe XML construit en mmoire par le 'parser'. C'est un
moyen, mais ce n'est pas le bon, si l'on veut rester performant :
	- une syntaxe doit s'adapter  la nature de la connaissance qu'elle dcrit : on n'crit
		pas du JAVA, du Lotus Script, du SQL, un document ou les formules mathmatiques dans
		la syntaxe XML. Chaque domaine dispose d'une syntaxe approprie, partage, ne du bon
		sens et du besoin de clart. Une syntaxe XML ne ferait qu'ajouter de la lourdeur et
		plomber radicalement la productivit.
	- le graphe XML n'est pas adapt pour reprsenter proprement un graphe de parsing. Pour
		rsumer, un graphe XML s'tale sur deux	dimensions, et consiste  relier des noeuds
		de nature diffrente (entits/attributs/lments) avec des branches. Il est pnible de
		piocher de l'information et de naviguer l-dedans. C'est trop verbeux et on peut
		s'garer entre les noeuds de diffrente nature.
	- la structure du graphe de parsing est le reflet exact du fichier XML. Cela signifie que
		la reprsentation conceptuelle de la connaissance dans un domaine particulier dpend
		de celui qui a produit le fichier XML. Je m'explique : Rational ROSE et Objecteering
		sont tous deux capables de reprsenter une modlisation UML. Chacun peut dfinir son
		propre format XML pour structurer la connaissance UML, et il ne se ressemblera pas
		s'ils ne se concertent pas avant pour participer  un format XML standard dans leur
		domaine. Chaque fichier XML aura une structure diffrente, donc un graphe de parsing
		diffrent, pour reprsenter pourtant la mme modlisation UML.
Il est malsain de penser que l'organisation de la connaissance dans le graphe dpende de la
source choisie. Une classe "Company" est un concept que vous manipulez dans votre cerveau de
la mme manire, qu'il provienne de la modlisation UML dessine sous Rational ROSE ou sous
Objecteering. Ceci permet d'appliquer derrire des schmas de pense identiques, quelle que
soit la provenance UML de cette classe.
Le graphe de parsing qui est finalement choisi prend en quelque sorte le rle de "format pivot",
c'est  dire que, pour reprendre l'exemple prcdent sur UML, les fichiers XML sont traduits
dans ce format, qu'ils proviennent de Rational ROSE ou de Objecteering.

Ainsi, et pour rester ouvert et performant, CodeWorker accepte toute sorte de fichiers de
description (tant qu'ils restent textuels et non pas binaires), avec les syntaxes les plus
farfelues, et il n'utilise pas un graphe de parsing XML.
Le langage de scripts permet de dcrire commodment la procdure de parsing de ces fichiers. Il
existe pour cela deux types de scripts ddis au parsing dans CodeWorker :
	- un script de parsing utilisant une grammaire EBNF pred-LL(k) (une syntaxe approprie 
		la description d'une syntaxe!),
	- un script de parsing utilisant des appels procduraux, classique dans un langage de programmation,
		mais moins bien adapt que la BNF,

Des scripts de parsing, qui seront bientt publis dans la rubrique "Scripts repository" du
site Web, ont t raliss pour :
	- lire une modlisation UML issue de Rational ROSE,
	- lire une modlisation Objet particulire, tendue de capacits que UML n'offre pas,
	- lire une DTD et gnrer automatiquement le parser/validateur XML  partir de l (XML a
		quand mme de l'intrt!),
	- lire du LaTeX et le retranscrire en HTML,
	- lire des IDLs CORBA,
D'autres ont t raliss dans le cadre de missions, et demanderont une refonte complte avant
d'tre publis (reprise de l'ide mais pas de l'implmentation,  cause des droits d'auteur).

Pour ceux qui ne trouveront pas leur bonheur, il leur restera la possibilit de dfinir leur
propre script de parsing en BNF, o tout est fait pour apporter le plus de puissance possible
sur le plan de l'expressivit et de la clart. Une fois les concepts du langage matriss, il
est trs rapide d'crire le script de parsing.


GENERATION DE CODE

La gnration de code est pilote elle-aussi par le langage de script. Sa syntaxe a t
spcialement tudie pour faciliter l'criture du processus de gnration de code. Elle
s'inspire de ce qui est dj utilis par JSP, PhP, ASP et qui permettent de raliser des
pages dynamiques (ou des translations, XLT par exemple). La diffrence essentielle
rside dans la non appartenance  un langage cible donn, HTML ou XML pour les cas voqus
ci-dessus. Ces scripts permettent donc de gnrer n'importe quoi dans n'importe quel langage
cible : C++, JAVA, HTML, LaTeX, "Mon Petit Format", ...
Il y aura dans quelques temps un serveur de pages dynamiques qui sera propos. Pour l'instant,
CodeWorker s'utilise comme un interprteur, qui acquiert les connaissances via des scripts
de parsing, et qui les reproduit au travers de scripts de gnration de code.

Jusqu' prsent, il a t utilis pour :
	- gnrer une grosse partie du gnrateur de code et de la documentation jointe,
	- gnrer une grosse librairie Financire en C++, avec un grand nombre de designs patterns
		et une extension de UML proposs pour rduire considrablement l'effort
		d'implmentation,
	- traduire automatiquement cette mme librairie en version possdant une gestion automatique
		de la mmoire, de manire  ce que les deux se maintiennent en parallle,
	- raliser un framework d'applications financires, qui automatise encore plus de tches
		de programmation qu'au sein de la librairie sus-cite,

Grce  la gnration de code, on dispose d'une ractivit qui dpasse de loin celle offerte
par les modeleurs UML ou autre, puisque le processus de gnration de code est totalement  la
main du dveloppeur. Il choisit donc les fonctionnalits et les voies d'implmentations qu'il
met en place.
En fait, la gnration de code permet de capitaliser sur les comptences de conception / implmentation
des ingnieurs. Il dcrit  un niveau suprieure leur dmarche d'implmentation face  des cas
de conception simples ou trs complexes. Cette dmarche est alors applique automatiquement
sur la modlisation acquise par parsing.
Grce  cette approche, l'ingnieur se dcharge des tches rptitives et ingrates, et dgage
beaucoup plus de temps sur l'architecture et la conception. Il devient de mme considrablement
moins impact par les modification faite sur la modlisation.

Des scripts de gnration de code seront publis (aprs rcriture complte, puisque appartenant$
 la socit o les projets relatifs  la Finance ont t implments):
	- gnration d'objets C++ et JAVA,
	- processus intelligent de srialisation / unmarshalling d'objets,
	- processus intelligent de navigation au travers d'objets pour y appliquer un traitement,
	- gnration du schma d'une base de donnes relationnelle + procdures stockes effectuant
		le mapping objets/relationnel + piste d'audit et rtro-corrections intgres + couche
		ct client qui cache la complexit d'appel  la base,
	- gnration automatique d'crans de saisie intelligents,
	- connection  un MiddleWare,


IMPACT SUR LES METHODES DE CONCEPTION / DEVELOPPEMENT

La ralisation du framework, couche qui touche  l'architecture, a permis de dcouvrir de
nouvelles mthodes de travail qui dcuplent la puissance de travail, en apportant tout  la
fois rigueur, robustesse et documentation pertinente.

Un framework touche  la fois  l'architecture des applications (intra/inter application), 
la conception et bien sr, au dveloppement.

Une rgle s'est avre d'une importance capitale : tout document de rfrence doit formaliser
les parties de description qui concernent une exploitation par la machine. Je m'explique :
supposons que des applications changent des messages via un bus multicast. Ces messages sont
formaliss dans un fichier qui dispose de sa propre syntaxe, et qui inclut des parties
explicatives. Partant de l, le document est mis  jour automatiquement, ce qui garantit la
qualit de son contenu, et le code source d'envoi/administration/recomposition du message,
intgr dans l'application, s'implmente automatiquement.

Une autre rgle, qui justifie la personnalisation de la syntaxe des fichiers de description,
stipule que plus d'informations seront reportes au niveau de la conception (informations
indpendantes du langage cible d'implmentation), plus de code source ou de documentation
pourra tre disponible, et sous diffrents langages (JAVA + VB ou HTML + LaTeX + fichier plat).

Pour ce qui touche au travail de dveloppement en quipe, des rgles doivent tre respectes
pour mettre en place un environnement de dveloppement performant. Trop techniques pour tre
dtailles ici, elles feront l'objet d'une explication dans le manuel de CodeWorker.
