Résumé : Cet article présente le processus de migration de Visual Basic 0 vers Visual Basic. Net. IL aborde tous les aspects de la migration, depuis l'analyse








télécharger 146.45 Kb.
titreRésumé : Cet article présente le processus de migration de Visual Basic 0 vers Visual Basic. Net. IL aborde tous les aspects de la migration, depuis l'analyse
page4/5
date de publication22.12.2016
taille146.45 Kb.
typeRésumé
ar.21-bal.com > comptabilité > Résumé
1   2   3   4   5

Définition de la stratégie de migration

Une fois que vous avez décidé de migrer la totalité ou une partie d'une application existante, vous devez déterminer comment exécuter la migration vers Visual Studio .NET de manière optimale. Une stratégie classique, à savoir module par module, est généralement recommandée. Toutefois, cette méthode n’est pas toujours réalisable, principalement en raison de l'architecture ou de la taille de l'application. Il est alors possible d'envisager l'un des processus de migration suivants :

  • Migration verticale, nécessitant l'isolation et le remplacement d'un élément de votre application dans l'ensemble des n couches.

  • Migration horizontale, nécessitant le remplacement d'une couche entière de votre application.

Pour garantir l'équivalence fonctionnelle, quelle que soit la stratégie choisie, vous devez mettre en place des jeux de tests complets pour l'ensemble du système, mais aussi pour les modules, couches ou éléments individuels de migration.

Nous allons maintenant décrire en détail les stratégies de migration horizontale et verticale des applications, afin de vous aider à identifier la solution la mieux adaptée à l'architecture de votre solution. Les concepteurs de l'architecture de l'application doivent être impliqués dans le choix de cette stratégie.

Migration verticale

Dans la stratégie de migration verticale, vous identifiez et sélectionnez une ou plusieurs parties de l'application à faire migrer, ces parties traversant plusieurs, voire toutes, les couches de l'application. De fait, cette procédure revient à extraire une partie de l'application qui n'interagit que très peu avec les autres parties afin de la faire migrer.

Si les parties de l'application sont parfaitement isolées entre elles, la migration verticale peut être appropriée. Ces parties isolées partagent généralement très peu d'informations avec le reste de l'application. Elles se prêtent donc bien à la migration, avec un impact minimal sur le reste du système. Si vous devez ajouter une nouvelle fonctionnalité à l'une ou à plusieurs de ces parties à faire migrer, il est fortement recommandé de développer cette fonctionnalité à l'aide du .NET Framework.

Les scénarios suivants représentent deux cas pour lesquels la migration verticale est la meilleure solution.

Usage intensif de jeux d'enregistrements ADO entre les couches

De nombreuses applications passent des jeux d'enregistrements ADO déconnectés de la couche de données ou d'entreprise vers la couche de présentation. La couche de présentation effectue ensuite une itération sur les jeux d'enregistrements, puis génère des tables HTML. La migration verticale convient particulièrement à ce type d'application. Ici, par exemple, la concentration des efforts sur la migration d’ADO vers ADO.NET minimiserait le travail nécessaire pour garantir une interopérabilité avec ADO.

Nouveau développement

La migration verticale de plusieurs parties de votre application vers la nouvelle architecture constitue un banc d'essai idéal si vous choisissez d’effectuer un nouveau développement. .NET Framework offrant un nouveau support architectural, votre tâche sera simplifiée si vous en tenez compte dans votre nouveau développement. Par exemple, vous pouvez utiliser des gestionnaires HttpHandler dans Visual Studio .NET pour exécuter beaucoup des tâches pour lesquelles vous auriez utilisé des extensions ISAPI auparavant, mais vous bénéficiez maintenant d’un modèle de programmation beaucoup plus simple.

Dans le cadre de la stratégie verticale, une fois que la partie sélectionnée a été migrée, toute intégration entre le nouveau code managé et le code non managé existant se fait par le biais de l'interopérabilité. Diverses tâches de développement et de test seront nécessaires pour vous assurer que les anciens et les nouveaux composants du site interagissent correctement, qu'ils partagent les données et qu'ils offrent une interface transparente à l'utilisateur. Vous disposerez alors de l'infrastructure de base qui vous permettra de poursuivre la migration d'autres applications dans le système à l'aide de la même stratégie de migration verticale, ou d'étendre la partie migrée de l'application.

Migration horizontale

Dans la stratégie de migration horizontale, vous faites migrer une couche entière de l'application vers Visual Studio .NET, sans toucher aux autres couches dans l'immédiat. En optant pour la migration d’une seule couche à la fois, vous pouvez tirer parti des fonctionnalités spécifiques qu'offre le .NET Framework pour cette couche particulière. Dans la plupart des cas, il n'est pas nécessaire de modifier le code de l'application, et le fonctionnement des autres couches de l'application n'est pas affecté.

La première étape de la stratégie de migration horizontale consiste à choisir la couche à faire migrer.

La migration de composants COM de couche intermédiaire vers Visual Studio .NET ne nécessite que très peu de modifications (voire aucune) au niveau de la couche de présentation. Tenez compte des points suivants pour déterminer si la stratégie de migration horizontale est appropriée, et si c'est le cas, pour savoir quelle couche il convient de faire migrer en premier.

  • Nombre élevé de serveurs Web : le déploiement d'une application Visual Basic .NET requiert que le CLR soit installé au préalable sur chaque serveur Web. Par conséquent, le déploiement de votre application sur une batterie de serveurs Web peut poser problème. Si l'application compte un nombre sensiblement moins élevé de composants de couche intermédiaire, il est préférable de commencer par la migration horizontale de la couche intermédiaire.

  • Migration de code partagé : si, comme c'est généralement le cas avec le code Visual Basic, la couche intermédiaire compte une grande quantité de code partagé, de constantes ou de bibliothèques personnalisées, il peut être judicieux de migrer d'abord cette couche, afin de faciliter la migration de l'ensemble de l'application par la suite.

  • Couche intermédiaire complexe : les hiérarchies d'objets complexes de la couche intermédiaire doivent être traitées comme un tout. L’isolation d’une application comportant une couche intermédiaire complexe, peut s’avérer difficile. En outre, si vous ne migrez que quelques éléments d'une couche intermédiaire complexe, de nombreux appels d'interopérabilité seront nécessaires, ce qui entraînera une diminution des performances.

Lors du remplacement de la couche intermédiaire, vous devez également tenir compte des points suivants :

  • Lorsque vous remplacez de façon transparente des composants de la couche intermédiaire par des composants .NET sans modifier le code client, vous devez conserver les GUID et/ou les ProgID d'origine de vos composants COM.

  • Lorsque vous tentez de remplacer de façon transparente un composant COM, vous devez correctement gérer le remplacement de l'interface de classe générée par les composants Visual Basic.

  • Les datasets ADO.NET renvoyés par les composants remplacés de la couche intermédiaire doivent être convertis en ensembles d’enregistrements ADO utilisés dans votre code Visual Basic d'origine.

  • Les assemblages (assemblys) d'interopérabilité doivent être déployés pour les composants de couche intermédiaire.

Estimation des coûts

L'estimation des coûts et de la durée des projets de développement logiciel est souvent complexe. En effet, elle peut varier considérablement en fonction de la qualité des implémentations logicielles, mais aussi des capacités des équipes en termes de programmation. Il en est de même pour la migration du code. De nombreux facteurs peuvent affecter le travail requis pour la mise à niveau des applications. Ces facteurs peuvent générer une différence de coûts variant d'une application à une autre, mais également d'une entreprise à une autre. Nous allons donc vous présenter les facteurs susceptibles d'affecter les coûts, afin que vous puissiez les analyser dans le contexte de votre application et de votre infrastructure, afin d'estimer le coût de votre migration.

Lors de l'évaluation du coût final de la migration de vos applications, nous vous recommandons de tenir compte des facteurs suivants :

  • Résolution de fonctionnalités non gérées : pour chacune de ces fonctionnalités, estimez le coût des solutions de remplacement, les coûts du développement et du test des fonctionnalités requises pour la solution retenue, ainsi que le coût du remplacement de la fonctionnalité non gérée multiplié par son nombre d’instances dans l'application migrée.

  • Résolution des problèmes détectés : estimez le coût de correction des erreurs signalées dans le rapport de mise à niveau. Pour ce faire, il est recommandé d'effectuer un exercice de migration pilote, couvrant une partie représentative de l'application, afin d'obtenir des informations précises sur le coût de la résolution des problèmes détectés. Vous aurez alors également des informations importantes quant à la capacité de votre équipe à migrer l'application.

  • Tests : pour chaque projet Visual Basic de l'application, il convient d'estimer le coût des tests nécessaires. L'exercice de migration pilote recommandé ci-dessus devrait également fournir des informations importantes sur ces tests. Vous devez déterminer si vos jeux de tests actuels doivent être étendus ou modifiés pour garantir avec précision l'équivalence fonctionnelle dans un premier temps, puis les nouvelles fonctionnalités de l'application migrée. Évaluez les coûts engendrés par une telle extension ou modification.

Il est également important de comprendre et d'évaluer l'ampleur des tests requis sur l'application .NET migrée, par rapport aux tests courants (parfois partiels) exécutés sur une version de Visual Basic 6.0. Il peut en ressortir que l'exécution de l'ensemble des jeux de tests sur l'application migrée nécessitera plus de temps, et dans certains cas plusieurs itérations, ce qui affectera le coût de la phase de test.

  • Remplacement des composants Visual Basic 6.0 par des équivalents .NET : pour chaque composant Visual Basic 6.0 que vous envisagez de remplacer par un équivalent .NET et que l'Assistant Mise à niveau Visual Basic ne peut pas remplacer, évaluez le coût du remplacement manuel, en prenant soin de le multiplier par le nombre d'occurrences dans l'application migrée.

  • Composants .NET tiers : vérifiez le coût des licences de tous les composants .NET que vous envisagez d'utiliser dans l'application migrée auprès de leurs fournisseurs respectifs.

  • Nouvelles fonctionnalités : faites une estimation du coût de la conception, du développement et des tests des nouvelles fonctionnalités de l'application migrée, en vous basant sur d'anciens projets de développement dans l'entreprise.

  • Déploiement : évaluez le coût de déploiement de l'application migrée. En règle générale, les applications .NET offrent un mécanisme de déploiement beaucoup plus simple que les anciennes applications COM.

Par ailleurs, lors de l'estimation des coûts, il peut être nécessaire d'étudier d'autres facteurs inhérents à votre entreprise. Pour analyser ces autres facteurs, vous pouvez vous référer à d'anciennes estimations de coûts préparées dans l'entreprise pour d'autres projets de développement logiciel. Les facteurs affectant les coûts au sein d'une entreprise sont généralement les suivants : disponibilité de ressources techniques, capacités des équipes chargées du développement et des tests, disponibilité d'une infrastructure pour l'implémentation d'une nouvelle technologie.

À l'aide de toutes ces informations, vous pourrez établir le coût estimatif (heures de travail) du projet de migration. D'après ArtinSoft, l'une des principales différences entre la structure d'un projet traditionnel et celle d'un projet de migration est la suivante : alors que dans un projet traditionnel, la phase de test représente 20 à 30 % du coût total, dans un projet de migration, elle peut aisément atteindre 60 à 70 %, le nombre absolu d'heures pour le projet étant beaucoup moins élevé.

Plan de migration

Lors de la planification d'une migration Visual Basic, nous vous conseillons d'allouer du temps supplémentaire aux tâches suivantes, en plus des tâches généralement incluses par votre entreprise dans un projet de développement logiciel :

  • Définition et révision de l’objectif

  • Architecture actuelle et architecture cible

  • Analyse et conception de nouvelles fonctionnalités

  • Sélection de la stratégie de migration

  • Inventaire à faire migrer

  • Préparation du code source

  • Métriques du code source

  • Gestion des fonctionnalités non prises en charge

  • Évaluation des données du rapport de mise à niveau

  • Pour chaque projet

    • Migration du projet à l'aide de l'Assistant Mise à niveau de Visual Basic

    • Stabilisation (résolution des problèmes liés aux fonctionnalités non mises à niveau/non prises en charge et résolution des problèmes liés aux différences de comportement)

    • Test par unité

    • Nettoyage et distribution

  • Validation de l'équivalence fonctionnelle

  • Implémentation de nouvelles fonctionnalités

  • Recette du projet et derniers tests

  • Déploiement

Toutes ces tâches ont déjà été abordées dans ce document.

Exécuter la migration

Selon ArtinSoft, plusieurs données déterminent comment la migration doit être exécutée : la stratégie de migration choisie, l'ordre dans lequel les projets sélectionnés dans l'application seront migrés, le contenu du rapport de mise à niveau et l'arborescence des dépendances de l'application. Il est fortement recommandé de commencer par faire migrer les projets avec peu de dépendances et contenant uniquement quelques fonctionnalités non mises à jour/non prises en charge (voir la section Évaluer les données du rapport de mise à niveau).

Pour chaque projet Visual Basic 6.0, le processus de migration général se compose des tâches suivantes :

  1. Mettre à niveau le projet à l'aide de l'Assistant Mise à niveau de Visual Basic.

  2. Stabiliser le projet migré en :

    • Exécutant une compilation complète. Pour ce faire, vous devrez résoudre tous les problèmes liés aux fonctionnalités non mises à niveau/non prises en charge au préalable.

    • Examinant les problèmes liés aux différences de comportement qui ont été détectées.

  3. Effectuer un test d’ensemble sur le projet migré.

  4. Nettoyer le code source en supprimant les notes de mises à niveau et les commentaires se rapportant aux problèmes ; rendre accessible le projet migré pour permettre l'implémentation de nouvelles fonctionnalités ; migration, à l'aide du même processus, de tous les autres projets concernés.

EMBED PBrush

Figure 3. Processus de migration de chaque projet d'une application

Le processus de migration sera plus rapide si le code a été préparé au préalable (voir la section Préparer le code pour la migration).

Notez que les composants ActiveX et COM tiers qui ne sont pas identifiés par l'Assistant Mise à niveau de Visual Basic ne seront pas automatiquement remplacés par un équivalent .NET, mais qu'ils seront utilisés par le biais de l'interopérabilité. En général, aucun problème ne sera signalé dans ce cas, mais si vous envisagez de les remplacer par un composant .NET, le remplacement devra être manuel.

1   2   3   4   5

similaire:

Résumé : Cet article présente le processus de migration de Visual Basic 0 vers Visual Basic. Net. IL aborde tous les aspects de la migration, depuis l\3 tiers d’architecture, 100% de Visual Basic Les composants
«bout code» qu’il faut rajouter dans le code d’une application principale. IL arrive, d’ailleurs, fréquemment qu’un composant soit...

Résumé : Cet article présente le processus de migration de Visual Basic 0 vers Visual Basic. Net. IL aborde tous les aspects de la migration, depuis l\Introduction à ado. Net avec Visual Basic 2005

Résumé : Cet article présente le processus de migration de Visual Basic 0 vers Visual Basic. Net. IL aborde tous les aspects de la migration, depuis l\Ied java jee
«Visual Basic vers Java» de l'application de gestion des sinistres de la société

Résumé : Cet article présente le processus de migration de Visual Basic 0 vers Visual Basic. Net. IL aborde tous les aspects de la migration, depuis l\Java 2ee (Jsp Servlet Ejb jpa/Hibernate Spring Jsf “Seam : notions”...

Résumé : Cet article présente le processus de migration de Visual Basic 0 vers Visual Basic. Net. IL aborde tous les aspects de la migration, depuis l\Résumé Ce guide décrit la connexion et la migration des systèmes...

Résumé : Cet article présente le processus de migration de Visual Basic 0 vers Visual Basic. Net. IL aborde tous les aspects de la migration, depuis l\Comment bien préparer sa migration de Microsoft Online Services (bpos) vers Office 365

Résumé : Cet article présente le processus de migration de Visual Basic 0 vers Visual Basic. Net. IL aborde tous les aspects de la migration, depuis l\I déploiement d’application Windows avec Visual Studio. Net
...

Résumé : Cet article présente le processus de migration de Visual Basic 0 vers Visual Basic. Net. IL aborde tous les aspects de la migration, depuis l\Résumé Cet article aborde la question de la nouvelle gouvernance...
«un ordre inventé», résultant de la confrontation de l’économique et du politique. (Donzelot, 1984; Castel, 1995)

Résumé : Cet article présente le processus de migration de Visual Basic 0 vers Visual Basic. Net. IL aborde tous les aspects de la migration, depuis l\Calendrier de migration 34

Résumé : Cet article présente le processus de migration de Visual Basic 0 vers Visual Basic. Net. IL aborde tous les aspects de la migration, depuis l\Curriculum vitae
«La migration et les relations internationales contemporaines en Europe (entre le xx° et xxi° siècles)»








Tous droits réservés. Copyright © 2016
contacts
ar.21-bal.com