Discussion :

[narutobaka]

Bonjour,

Je travaille actuellement sur l'analyse du code d'un projet développé en Delphi pour en faire une adaptation en VB.NET.

Cependant je suis loin d'être un expert dans l'analyse de code et je patauge légérement (même bp d'ailleur), bien que je connaisse Delphi et le Vb.net.

Je recherche des conseilles surtout concernant la méthodologie pour rédiger les différents documents dont le cahier des charges, permettant de reprendre le développement en VB.net de ce programme.

Je suis preneur de tout conseil sur le sujet.

cordialement

[Hephaistos007]

Tu comptes faire la traduction manuellement (avec ta tête) ou automatiquement (avec un logiciel) ?

[narutobaka]

Bonjour,

Actuellement je me paluche le code du programme Delphi/Pascal à la main, je dispose de tous les sources.

Cependant, il n'y a pas de doc technique et les commentaires dans le code ne sont pas à jour.

Je recherche une orientation me permettant à moi et à mon collègue (qui lui ne connait pas le Pascal) de pouvoir traduire cette application métier en VB.net le plus simplement possible et avec le moins de "perte".

Si l'une de ces méthodologies impliquent une méthode automatique je suis preneur aussi. Mais je recherche surtout un fil conducteur me permettant de rediger les documents qui à terme formeront le cahier des charges pour le programme en VB.net. Savoir ce qui est important de mettre, comment le formaliser, comment le présenter sous quel forme .....

Je ne suis qu'un développeur débutant, et c la première fois que j'interviens sur un projet déjà existant dont je dois extraire les spécificités. J'avoue cependant que l'absence de documentation technique, voir du cahier des charges originals me complique significativement le travail.

J'apprécie l'aide de toute personne ayant de l'expérience dans ce type de projet, en vous remerciant d'avance

cordialement

[Richard_35]

Bonjour Narutobaka,

Eh bien, tu es gâté, pour tes débuts...

Il peut y avoir 2 macro-techniques :

1. prendre les sources, un par un, et traduire "mot à mot" les instructions Delphi en VB ;
2. segmenter le travail pour arriver aux sources.

Personnellement, je penche pour la seconde méthode, à savoir :

• repérer, dans l'application Delphi, côté "métier" (utilisateur), les groupes d'application, en établir la liste et associer les noms des programmes correspondants ;
• travailler donc par ensemble de programmes appartenant à un même groupe d'application ;
• comprendre, du point de vue "métier", la fonction d'un programme ;
• repérer les tables/vues/requêtes en entrée ;
• repérer les tables en sortie ;
• étudier le code intermédiaire ;
• transcrire en VB.

Si ton collègue ne connais pas Delphi, il peut se charger de comprendre, du point de vue "métier", les groupes d'application.

Plus facile à dire, qu'à faire... je suis d'accord.

[narutobaka]

Bonjour,

Apperemment je fais déjà une sorte de mixe de ta solution Richard_35.

repérer, dans l'application Delphi, côté "métier" (utilisateur), les groupes d'application, en établir la liste et associer les noms des programmes correspondants ;

Le Projet en Delphi est une solution découpée en plusieurs applications, elles sont correctement hiérarchisé chaque formulaire d'affichage étant groupé à l'application dont il dépend, à quelque exception près pour les formulaires commun à plusieurs applications (ces derniers sont chiants a identifier dans le code parfois )

Actuellement je suis novice en ce qui concerne la partie métier de l'application et je me limite à relever où sont effectués les appels aux procédures stockées.

J'édite actuellement un fichier texte (.doc) par application.

travailler donc par ensemble de programmes appartenant à un même groupe d'application ;

Euh la j'avoue ne pas comprendre ta nuance pour les programmes, fais tu référence au formulaire d'une application ?

comprendre, du point de vue "métier", la fonction d'un programme ;

Pour cette partie je dispose d'une version compilé de l'application que j'utilise pour voir comment intéragir avec l'application, est-ce bien à cela que tu fais référence?

repérer les tables/vues/requêtes en entrée ;
repérer les tables en sortie ;

J'avoue ne pas comprendre cette partie. Fais-tu référence aux intéractions avec la base de donnée? Si c'est le cas je n'ai accès qu'au appel de procédure stockée.

étudier le code intermédiaire ;

La je restranscrit en pseudo code le code Delphi en passant chaque source en revu ( c'est pour ca que je dis que je fais un mix de tes 2 solutions)

transcrire en VB.

Pour l'instant il n'est pas encore question de code VB (de mon coté en tout cas ) tant que je n'ai pas encore finalisé le cahier des charges des fonctionnalité du projet Delphi.

Je transmet mes fichiers (.doc ) à mon collègue, qui lui travaille déjà sur le programme en Vb, en utilisant des objets existant déjà dans la bibliothèque de la société afin qu'il puisse me dire ce qui lui manque pour les objets que l'on va utiliser. Certains objets existent mais ils ne remplissent pas complétement les fonctionnalités pour ce projet, il faut donc les adapter.

Ce que je recherche c une sorte de document technique type me permettant de représenter au mieux les informations du projet Delphi.

Je patauge surtout sur la facon de bien représenter les functions / procedure d'un formulaire, surtout quand il s'agit d'événementielle.

Ou encore ou indiquer ou comment documenter les structures de données. Dois-je les inclures la ou elle sont utilisés ou en faire un document à part, en suivant le découpage de l'application, les types et déclarations globales étant dans un fichier à part.

Existe-t-il une méthodologie normée pour ce genre de tache?

Merci pour vos conseil

++

[Higgins]

Hello,

Il n'y a malheureusement pas de solution miracle. Peu d'outils te feront ça en automatique. Il y a quelques années, j'ai fait le test avec Entreprise architect (Sparx). J'ai remonté mes classes Delphi dans l'appli, puis regénéré du code c#.
Mais il n'a créé que les unités et les entêtes des méthodes. Après, il faut se palucher la traduction du code (j'ai vite laissé tomber).
Tu peux toujours télécharger la version d'éval (30j) pour tester s'ils ont progressé.

[Richard_35]

Bonjour Narutobaka,

*1*

travailler donc par ensemble de programmes appartenant à un même groupe d'application ;

Euh la j'avoue ne pas comprendre ta nuance pour les programmes, fais tu référence au formulaire d'une application ?

==> oui.
*1*


*2*

comprendre, du point de vue "métier", la fonction d'un programme ;

Pour cette partie je dispose d'une version compilé de l'application que j'utilise pour voir comment intéragir avec l'application, est-ce bien à cela que tu fais référence?

==> oui. Si tu restes dans cette boîte, de toutes manières, il faudra maîtriser, un tant soit peu, l'application métier. Donc, mieux tu connaîtras l'application, mieux tu la traduiras (ce n'est pas de Lao Tseu, mais ça y ressemble, je trouve...).
*2*


*3*

repérer les tables/vues/requêtes en entrée ;
repérer les tables en sortie ;

J'avoue ne pas comprendre cette partie. Fais-tu référence aux intéractions avec la base de donnée? Si c'est le cas je n'ai accès qu'au appel de procédure stockée.

==> oui. Il est obligatoire de connaître les intéractions entre les formulaires et la BdD.
*3*


*4*

Ce que je recherche c une sorte de document technique type me permettant de représenter au mieux les informations du projet Delphi.

Je patauge surtout sur la facon de bien représenter les functions / procedure d'un formulaire, surtout quand il s'agit d'événementielle.

Ou encore ou indiquer ou comment documenter les structures de données. Dois-je les inclures la ou elle sont utilisés ou en faire un document à part, en suivant le découpage de l'application, les types et déclarations globales étant dans un fichier à part.

Existe-t-il une méthodologie normée pour ce genre de tache?

==> comme le dit Higgins, je ne connais pas de solution miracle, ni de documentation normée.

Concernant la documentation technique, ma suggestion était la suivante :

• détermination des groupes de l'application ;
• 1 document par formulaire avec indication de son groupe ;
• liste des tables/requêtes/vues en entrée : les données lues ;
• liste des tables/requêtes/vues en sortie : les données créees/modifiées/supprimées ;
• étude du code intermédiaire : liste des événements et leur fonction.

==> classement des ces documents par groupe de l'application.
*4*

Perso, c'est à peu près comme cela que je procéderais... mais bon, c'est juste une suggestion qui peut servir de base de travail améliorable.

[narutobaka]

bonjour,

Oui Higgins, merci d'intervenir sur mon post ( suite à mon mp ), j'ai en effet lu ton message sur le forum, mais tu ne donnais pas d'information suite à ton utilisation du logiciel.

J'aurais aimé savoir comment tu as procédé pour la création de ta doc technique avant développer sous Vb.net??

++

[Higgins]

...tu ne donnais pas d'information suite à ton utilisation du logiciel.

Comme je l'indique dans mon précédent post, il n'y a pas eu de suite, j'ai laissé tomber.
L'outil permet de générer un diagramme de classe par reverse engeneering du code, mais il ne sais pas traduire le code source correspondant dans un autre langage. C'est à dire que si tu lui fais générer du code VBnet à partir du modèle, la structure sera correcte (déclaration de classes, en-têtes de fonction,...) mais le code à l'intérieur de la fonction restera en Delphi.

J'aurais aimé savoir comment tu as procédé pour la création de ta doc technique avant développer sous Vb.net??

Je n'ai jamais développé en VBnet, dans mon cas c'était du C#.....et je n'ai pas créé de doc technique, puisque j'ai lâché l'affaire.