Analyse de la migration de FMStocks 2000

Sur cette page

Introduction
Fmstocks 2000
Migrer ou ne pas Migrer ?
Etude de faisabilité
Conclusion
Evaluation et Analyse de FmStocks 2000
Vue d’ensemble de la Structure de FMStocks
Vue d’ensemble des scénarios fonctionnels :
Inventaire de FMStocks 2000
Métriques du code source et Fonctionnalités non supportés
Analyse des dépendances

Introduction

Ce que je me propose de réaliser dans cet exercice, c’est de migrer la célèbre application Visual Basic 6.0, FMStocks 2000 (Fitch & Matter) vers Visual basic 2005.
Je n’ai pas réinventé la roue, j’ai décidé de reprendre l’étude de cas qui avait été faite pour le guide de migration Upgrading Visual Basic 6.0 Applications to Visual Basic .Net and Visual Basic 2005.

Néanmoins, pour pouvoir être le plus objectif possible, j’ai essayé de me mettre dans les conditions qui se rapproche le plus de la réalité (de ma réalité en fait) et d’appliquer à moi même ce que le guide de migration préconise. Je vais donc essayer de réaliser une Migration de l’application, en chiffrant l’effort et le coût du travail à accomplir dans cette démonstration. En un mot combien a couté à Microsoft France ma démonstration

Mais avant de continuer quelques mots sur FmStocks 2000

Haut de page

Fmstocks 2000

C’est un exemple d’application Microsoft Windows Distributed InterNet Application Architecture (Windows DNA) qui simule l’achat et la vente d’actions sur internet.
Elle est intéressante car elle est basée sur une architecture 3 Tiers, mettant en œuvre une couche présentation (ASP), une couche Métier (VB6 et COM+) et une couche Accès aux données basée sur ADO.

Haut de page

Migrer ou ne pas Migrer ?

Il est naturel de se poser cette question, et le guide vous donne toutes les bonnes pistes pour y parvenir. Je ne reviendrais pas sur tous les détails de ce guide et sur toutes les questions à se poser, mais pour pouvoir répondre à cette question, il semble donc nécessaire avant tout de faire une étude de faisabilité afin de pouvoir la soumettre à mon boss.

Haut de page

Etude de faisabilité

Prendre la décision de faire évoluer une application particulière implique qu’elle a une valeur importante pour l’entreprise il est donc important d’y accorder tout son attention.
Pour pouvoir continuer mon projet de Migration, il a fallu que je vende le projet à mon boss.
Je savais que les premières questions qu’il allait me poser tourneraient autour de :

Qu’est-ce que cela apporterait en terme métier ?
Combien cela prendrait comme temps ?
Quelle est l’impact sur mon implication des autres projets en cours ?

Pour continuer mon étude de faisabilité, il faut que je sois capable de mesurer la charge de travail et l’évaluer techniquement. N’ayant pas de connaissance préalable sur l’application, il faut que je puisse me l’approprier. Cela prendra sans doute plus de temps, que si j’y avais contribué. Si vous avez un développeur qui a participé à l’élaboration de l’application, il est important de le mettre dans le circuit d’étude de faisabilité, mais cela tombe sous le sens. Néanmoins, la plupart du temps, il n’est pas facile d’avoir sur la main un développeur qui connait l’application de A à Z. Qui n’a pas une application qui a évoluée d’année en année, de VB 3 à VB 6 et ou les ressources humaines sont parties depuis longtemps ?

Ma première tâche a donc consisté à :

Retrouver les codes sources ainsi que les binaires.

Disponibles sur le site Web de Fitch & Matter à cette adresse http://www.fmstocks.com/.
Effort Estimé : 1h

Installer l’application

Dans la plupart des cas, l’étude de l’application se fait avec les développeurs et les utilisateurs de l’application. Dans mon cas, je n’ai à ma disposition que le guide de migration, la documentation, et le code source. J’ai donc besoin d’installer l’application en état de fonctionnement. Et les problèmes commencent. En effet bien qu’il existe une procédure d’installation automatique sous forme de batch, toute l’installation ne fonctionne pas automatiquement. 3 batchs d’installation, concernant les 3 couches de l’application, respectivement installation des composants métier et accès aux données (setup-components.cmd), création du site Web pour la couche présentation (setup-web.cmd), et installation de la couche de persistance (setup-db.cmd) sont à lancer. Les deux premiers s’exécutent sans erreurs, mais le troisième plante. Ne voulant pas perdre trop de temps, je décide donc d’exécuter les scripts SQL Serveur manuellement et corriger les problèmes au fur et à mesure. Un script DTS (script qui permet de prendre des données d’une base Access et de les transférer dans la base SQL Serveur) n’a absolument pas fonctionné. N’étant pas un spécialiste, j’ai décidé de le faire manuellement avec Microsoft Access. C’est ce qui m’a pris le plus de temps. Là ou j’ai gagné du temps, c’est que l’environnement de développement et Serveur (IIS et SQL serveur) était déjà installé sur ma machine.
Effort pour l’installation : 1h

Test de l’application

Une fois installé, il faut tester l’application. Bien évidement ;-), cela ne fonctionne pas correctement, car comme je m’en doutais la chaîne de connexion n’a pas été mise à jour par le processus d’installation.
Après étude du code source Visual Basic 6.0, il faut changer soit dans le code source la chaine de connexion. Bien évidement comme ce n’est pas l’optimum, j’ai cherché du coté d’un objet COM + qui permet d’externaliser la chaine de connexion. Enfin le minimum requis fonctionne, je vais pouvoir m’atteler à la tâche la plus fastidieuse, l’étude de l’architecture.
Effort Estimé : 1h

Etude de l’architecture et du code source.

Ma collecte des données est assez restreinte. Je n’ai pas eu accès, ni aux documents de spécifications, ni au document concernant l’architecture bien qu’il devrait se trouver sur le site MSDN. Je me contenterais de la lecture de simple document, de l’aide, et surtout du code source.

Il existe pléthore d’outils, qui permet de faire une analyse fine des sources de l’application (Compuware, Novalys), et faire des analyses d’impacts si vous changez telle ou telle variable globale. Dans mon exercice, je me suis contenté d’utiliser l’outil « Assessment tool » disponible sur notre site (cf, en fin d’article la référence) afin de mesurer la quantité de code à Migrer.
Effort estimé recherche document + Exécution Assessment tools: 4h

Effort total estimé par l’outil : l’outil donne des mesures moyennes, que j’ai gardées en l’état, mais qui seront sans doute ajustées par la suite. Il y 4 modules analysés par l’outil (détails fournis dans le chapitre Analyse des codes sources)
Module core : 56h ($3269)
Module Events : 21h ($1209)
Module Office : 26h ($1540)
Module store : 33h ($1991)
Total : 136h ($8009)

A ceci, il faut ajouter la couche présentation ASP ou j’estime 40 heures de Travail.

Pour plus d’informations sur la migration ASP, allez à l’adresse suivante :
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dndotnet/html/convertasptoaspnet.asp
L’outil de migration : http://www.microsoft.com/france/msdn/aspnet/aspnet1_1/asp-to-aspnet.mspx

Compétence de l’équipe de développement

Un point important est l’expérience de l’équipe de développement, qui va prendre en charge le projet de migration. Dans notre cas, c’est très simple, l’équipe est formé d’une personne, c'est-à-dire moi. J’ai quelques années d’expérience dans les technologies Microsoft et je connais relativement bien la plate-forme .NET 2.0. Par contre, je ne suis pas un adepte d’ASP qui est la couche de présentation, je subodore que je vais devoir faire attention à cet aspect. Néanmoins à première vue, rien d’insurmontable.

Etude des scenarii de tests

Je n’ai pas réussi à obtenir les scénarii de tests, je vais donc devoir les réécrire (pour la version migrée) avec le module de test de Visual Studio Team System. C’est sans doute un point important sûr qui va consommer du temps, et sur lequel vous devez être attentif. Si vous avez des jeux de tests existants, posez vous la question de savoir, si-il est possible de les réutiliser.
Effort estimé : 24 h

Tableau récapitulatif de l’estimation de l’effort et du coût :

Voila l’estimation que j’ai vendu à mon boss, sachant que j’ai pris l’estimation brute donnée par l’outil d’analyse et que je n’ai absolument pas affiné. Je suis a peu prêt persuadé, que je pourrais revoir à la baisse l’effort demandé lors d’une analyse plus fine des données.

Pour conclure sur cette première étape « Etude de faisabilité », c’est qu’elle demande somme toute assez d’expérience, pour se tirer d’affaire. A mon avis (mais il n’engage que moi), pour gagner du temps, il faut la donner à un développeur expérimenté, qui soit à même de préparer l’environnement de développement, le système d’exploitation, les produits serveurs, et l’application elle-même, qui connaisse correctement l’architecture COM+ et les services associés. L’analyse de l’application m’a appris qu’il n’y avait pas énormément de codes à migrer, et mon expérience de la plate-forme Microsoft permettra sans doute à diminuer le nombre d’heures pour atteindre cet objectif, les chiffres annoncés n’étant d’ailleurs qu’une estimation.

Haut de page

Conclusion

La stratégie choisie, étant une stratégie de migration iso fonctionnelle, l’utilisateur aura sans doute l’impression d’exécuter la même application. Alors pourquoi migrer ?

• L’étude de faisabilité me démontre que je n’aurai sans doute pas trop d’efforts à fournir, dans un budget raisonnable.

• Le fait même de passer l’application, vers du .NET, m’ouvre des perspectives, que je n’aurai pas eu ou plus difficilement avec mon application traditionnelle.

  • Gain de performances

  • Robustesse et sécurité

  • Déploiement facilité

  • Productivité accrue

  • Si je souhaite qu’elle évolue plus facilement dans un second temps, et résiste aux différentes pressions extérieures, telles que l’arrivée de nouveaux systèmes d’exploitation (Windows Vista), de nouveaux Hardwares (64 Bits et dualcore), telle que la pénurie de ressources sur Visual Basic 6.0, qui seront sans doute de plus en plus chères à maintenir.

Mais avant de commencer la migration en elle même, il est important de rentrer plus en profondeur dans le code et l’architecture de l’application ceci afin de pouvoir la planifier de manière optimum.

Haut de page

Evaluation et Analyse de FmStocks 2000

Les principaux objectifs de la migration dans notre étude est donc de migrer de manière iso-fonctionnel, mais pas à n’importe quel prix, et surtout de manière structurée pour pouvoir accélérer le processus.
Pour ce second objectif, une bonne planification, incluant l’estimation, les tâches, les risques, et les problèmes rencontrés lors de la migration est importante.
L’analyse détaillée et complète de l’application est requise, incluant, l’analyse de la structure et de l’architecture, l’interaction entre les différents composants, les fonctionnalités de l’application, les technologies utilisées, le code source complet, les dépendances externes avec des librairies Tiers.
Les études de cas seraient également utiles pour planifier la migration et les tests.
Pour une évaluation complète, nous allons utiliser l’outil assessment tool développé par ArtInsoft et que vous trouverez en téléchargement à cette adresse :
http://msdn.microsoft.com/VBRun/default.aspx?pull=/library/en-us/dnpag2/html/VB6ToVBNetUpgrade.asp

Haut de page

Vue d’ensemble de la Structure de FMStocks

Pour identifier la structure de FMStocks 2000, la documentation, le code source et les rapports d’analyse de l’outil Assessment sont de bons points de départ.

Cette application se décompose donc, en trois couches.
La couche présentation, la couche métier et la couche accès aux données, calquant l’architecture Windows DNA

La couche métier se présente ainsi :

• FMStocks_Bus.vbp. Ce projet contient tout le code métier pour l’achat/vente d’actions en ligne. Il y quatre modules de classes, Account, Broker, Ticker, Version, plus un module helper de définitions d’API Win32

• FMStore_Bus.vbp. Ce projet contient le code métier pour l’achat/vente de livres en ligne. Deux modules de classes disponibles. Product et ShoppingCart, plus un module helper de définitions d’API Win32

• FMSTore_Events.vbp. Interface qui définie les événements de gestion de commande de commandes, pour l’achat/vente de livres en ligne

• FMStore_EvtSub2.vbp. C’est l’implémentation proprement dit de l’évènement de gestion de commandes pour l’achat/vente de livres en ligne

La couche d’accès aux données se présente ainsi :

• FMSStore_DB.vbp. Ce projet contient le code d’accès aux données pour l’achat/vente de livres en ligne. Il inclut deux modules de classes : Product et ShoppingCart

• FMSTocks_DB.vbp : Ce projet contient le code d’accès aux données pour l’achat/vente d’actions en ligne. Il inclut huit modules de classes, Account, Broker, Ticker, Version, DBhelper, Position, Product et ShoppingCart

Trois groupes de projets regroupent tous les projets ci-dessus :

1. FMS2000_Core.vbg. Ce groupe de projet inclus les projets FMStocks_Bus.vbp, et FMSTocks_DB.vbp

2. FMS2000_Store.vbg : Ce groupe de projet inclus les projets FMSStore_Bus.vbp, et FMSStore_DB.vbp

3. FMS2000_Event.vbg : Ce groupe de projet inclus les projets FMSStore_Events.vbp, et FMSStore_EvtSub2.vbp

Haut de page

Vue d’ensemble des scénarios fonctionnels :

Pour accomplir dans les meilleures conditions notre migration, il nous faut donc réunir tous les scénarios :

• Connexion d’un utilisateur existant

• Connexion d’un nouvel utilisateur

• Déconnexion

• Recherche de société ou des symboles de bourses

• Affichage de la synthèse du compte

• Affichage du portfolio

• Graphique du portfolio

• Achat d’actions

• Vente d’actions

• Vue d’un caddie

• Parcours de produits

• Etc

Exemple de scénario :


Estimation de l’effort : 2h

Haut de page

Inventaire de FMStocks 2000

Pour faire un inventaire de l’application, le plus simple pour moi a donc été d’utiliser l’outil assessment
Voici comment cela fonctionne.
Une fois l’outil installé (par défaut dans le répertoire "C:\Program Files\Microsoft Visual Basic 6.0 Upgrade Assessment Tool\")

• Activez dans la barre des tâches le bouton Démarrer/Microsoft Pattern & Practice/Microsoft Visual Basic 6 Upgrade Assessment tool

  

• Activez Bouton Next

• Entrez un nom du projet

• Cochez la case Group File, puis choisissez votre groupe de projet

  

• Précisez un répertoire de destination ou l’outil créera les rapports

• Puis Next pour finir l’analyse.
  Deux rapports sont générés, MainReport.xls pour l’estimation de l’effort et du coût et DetailedReport.xls qui liste en détails les composants de l’application.

Ouvrons le rapport DetailedReport.xls généré pour le groupe de projet FMS2000_Core.vbg pour avoir une idée de ce qu’il y a l’intérieur.

Figure 1 : Page principale du rapport DetailedReport.xls
On s’aperçoit que le module a été décomposé en plusieurs chapitres.

• Lines of code : Donne le nombre de lignes de codes par projet.

• Project files overview : Donne le nombre total de Fichiers, de modules de classes, de contrôles, de formulaires etc… utilisés dans le groupe de projet.

• 3rd Party Components Summary et Members : Résume en donnant leur fréquence d’utilisation les composants tiers utilisées, les méthodes et propriétés utilisées. Par exemple comme nous le verrons dans notre étude, ADO est considéré comme un composant Tiers et ADODB.RecordsSet.MoveNext() comme un membre.

• User Components Summary et Membres : Résume en donnant leur fréquence d’utilisation les composants, les méthodes et propriétés du groupe de projet FSMStocks_core.

• VB6 Intrinsinc Components Summary et Members : Résume en donnant leur fréquence d’utilisation les composants, les méthodes et propriétés des objets VB6 utilisés. Ces objets faisant partie des bibliothèques VBA et VBRUN peuvent ne pas avoir leur équivalent avec la plate-forme .NET.

• API Calls : Représente bibliothèque utilisée les noms des API utilisées ainsi que leur fréquence.

• Data access : Résume l’utilisation des composants d’accès aux données ADO, RDO et DAO.

• COM + Summary et Membres : Rapport qui précise si le projet utilise des classes COM+ ou MTS (Microsoft Transaction Server).

• User COM Summary et Membres : Définie les objets COM utilisés et leurs type (EXE, DLL, etc..).

• Upgrade issue table : Ce rapport est important (surtout pour les développeurs), car il liste tous les problèmes que l’outil de migration automatique, ne pourra pas migrer. Dans ce rapport, vous aurez un directement un pointeur sur internet

• Missing components : Donne la liste des composants manquants

• Missing Files :

• Upgrade Order : Donne une recommandation sur l’ordre de migration.

Allons maintenant plus dans les détails de notre application FMStocks 2000

Tableau 1 : Groupe de projet FMS2000_Core

Tableau 2 : Groupe de projet FMS2000_Store

Tableau 3 : Groupe de projet FMS2000_Event

Comme nous pouvons le constater certaines colonnes sont vides, telle que UserControl, Designer et surtout la dernière colonne concernant l’interface utilisateur, les Forms. Cela indique qu’aucune de ces fonctionnalités ne sont présentes dans notre projet.

Le fait même de ne pas avoir d’interface utilisateur à migrer, me permet de préciser que l’effort de migration sera moindre. En effet, il est clair qu’une application à base de Formulaires Visual Basic 6.0, sera probablement plus longue à migrer qu’une application qui présente un large pourcentage de classes. La technologie Windows Forms de la plateforme .NET est bien différente de celle des formulaires Visual Basic 6.0, et l’expérience a montré que ces versions de Visual Basic. Qui n’a pas chez lui une application Visual Basic 6.0, avec du code source qui a été écrit avec Visual Basic 3.0 ?

Pour connaitre les détails d’une migration de Formulaires Visual Basic, voir le chapitre 9 « Upgrading Visual Basic 6.0 Applications to Visual Basic .Net and Visual Basic 2005 ». )

D’après les chiffres, le groupe de projet FMS2000_Store est le plus important, car en analysant les dépendances (Onglet 3rd Components), on s’aperçoit qu’une référence au composant FMSTocks_DB est présente, ainsi qu’une référence au composant FMSTore_Events.

L’assistant de migration ne sait migrer que projet par projet. Si je migre de FMSStore_bus.vpb, l’assistant créera automatiquement deux dlls d’interopérabililité (Cf. Chapitre 14 du guide de migration)sfaisant référence à FMSStore_Events et FMSTocks_DB. Concernant l’ADODB, l’assistant utilise une dll d’interopérabilité qui est présente lors de l’installation du Framework.NET.
Dépendant de l’ordre de Migration que je vais choisir. Si les projets FMSStore_Events et FMSTocks_DB sont déjà migrés, il me faudra alors remplacer les appels et les références aux dlls d’interopérabilité, par leur équivalent migré en .NET.

Concernant l’ADO, je ne ferais aucune modification, ni réécriture de code, je l’utiliserai en l’état. N’oubliez pas que je reste dans une stratégie iso-fonctionnelle.

Tableau 4 : Dépendance avec des composants Tiers de FMS2000_Store

Tableau 5 : Méthodes et Propriétes

Ce rapport permet de localiser plus rapidement les appels aux composants tiers, afin de pouvoir faire les modifications qui s’imposent.

Les rapports de l’inventaire pour l’accès aux données, ainsi que pour les API Windows, me confortent dans l’idée qu’il n’y aura pas trop de travail pour le composant d’accès aux données.
Néanmoins, même si le code sera sans doute très identique à l’origine, il faudra le tester.

Tableau 6 : Rapport d’accès aux données et Appel d’API

Tableau 7 : Rapport d’appels d’API Windows

Haut de page

Métriques du code source et Fonctionnalités non supportés

Pour une estimation de l’effort et du coût vous devez connaitre le nombre de lignes de code source de chaque projet. Le tableau 8 donné par l’outil vous en donne déjà une bonne précision.

Tableau 8 : Nombre de lignes de codes pour le groupe de projet FMS2000_Core

Tableau 9 : Fonctionnalités non migrées.

Pour ce groupe de projet, j’ai 1317 lignes de codes à migrer.
Je sais que 186 lignes ne seront pas migrées automatiquement soit environ 14% du groupe de projet

Haut de page

Analyse des dépendances

Pour définir l’ordre de migration, qui vous aidera à préparer vos plans de tests (voir à réutiliser vos jeux de tests existants), l’outil assessment propose plusieurs choix. Des fichiers html DependencyGraph.htm et CallGraph.htm (cf Figure 2 et 3) et dans le fichier DetailedReport.xls dans l’onglet Upgrade Order (Cf Tableau 10)

Figure 2 : Dépendances du groupe de projets FMS2000_Core

Figure 3 : Dépendances des appels de méthodes

On peut voir que tous les fichiers sont dépendants d’un fichier Helper.bas et ces méthodes associées.

Tableau 10 : Ordre de Migration recommandé

Les informations dans ce Tableau 10 sont plus ou moins redondantes avec ceux de la figure 2. Toutes ces données indiquent un point important. C’est que dans notre approche de migration ou de correction manuelle après migration automatique, nous commencerons par migrer les projets qui n’ont pas de dépendance. En l’occurrence ici le module du fichier Helper. Il faudra vérifier que ce fichier n’est pas 4 fois le même afin d’éviter de le migrer autant de fois qu’il est présent. Autant ne le migrer qu’une seule fois et le réutiliser dans les autres projets.

Jusqu’à présent, l’effort que ma couté ce projet de Migration est d’environ 12 heures.
Pour analyser 4943 lignes de codes dans 22 Fichiers ainsi que les 32 pages ASP

Haut de page

Téléchargez

Le code source
4,34Mo

Haut de page