Un grand merci à tous les présentateurs pour les sessions très détaillées et appuyées par des exemples et du code!

Retrouvez toutes les présentations sur le site www.DSLFactory.org.

Réussir la Migration vers .NET avec le “ Migration Center for .NET ”

en toute sérénité avec ATOS, COMPUWARE et MICROSOFT

Liste des articles publiés sur le sujet:

• Le Revenu.com
• new invest
• Voila
• Yahoo
• abcbourse
• AGEFI
• Boursorama
• Capital.fr
• cercle finance
• Club Internet
• Fininfo
• LaVieFinanciere.com
• LCI
• Le Journal des Finances
• Journal du Net
• ...

Comment aborder un projet de migration ?

Le projet de migration est toujours la bête noire de l’entreprise et ce pour plusieurs raisons différentes que je peux résumer de la sorte sans être exhaustif :

-          Le projet de migration est pressenti comme un projet cher et long avec une issue incertaine,

-          Peu gratifiant, car il faut reprendre des existants généralement bâtis sur des technologies ou des conceptions obsolètes (il n’est jamais facile de faire une autocritique d’un travail réalisé plusieurs années auparavant) et malgré tout cela fonctionne et donne satisfaction, alors pourquoi changer ?

-          Il sera nécessaire de former les personnes aux nouvelles technologies, acquérir de nouvelles compétences et de nouveaux outils pour accompagner ce changement, ce qui là encore implique un investissement…

Aborder un sujet de migration de la sorte ne conduit nul part et ne résout rien car, malgré tout, la planification du cycle de vie d’une application d’entreprise pérenne devrait toujours inclure un ou plusieurs cycles de migration et d’évolution (aussi appeler dans certains cas, rénovation). Que l’application ne soit pas évolutive ou migrable n’est pas toujours dû à la technologie, mais peut-être dû aussi à une mauvaise conception ou anticipation des évolutions à venir. Les choix opérés par l’architecte sur la conception initiale sont déterminants.

Pour aborder positivement un projet de migration, il est nécessaire de comprendre les facteurs qui nous poussent à migrer. L’ensemble de ces facteurs (il y en a généralement plusieurs, voir une combinaison de facteurs) forment la réponse à la question « Pourquoi dois-je migrer ? » que la personne détenant les capacités d’investissement ne manquera pas de vous poser à juste titre.

A titre d’exemple, voici quelques facteurs de migration :

-          Technologie vieillissante (exemple : Cobol, VB6…)

-          Volonté d’évoluer vers de nouvelles technologies (exemple : s’ouvrir au Web 2.0…)

-          Problèmes avec la technologie actuelle (exemple : performance…)

-          Contraintes métier (exemple : consolidation des applications…)

-          Réduction des coûts (exemple : nouvel environnement de développement plus productif…)

Lorsque les facteurs résultants (performance, coûts…) et les facteurs opportuns (opportunité, nouveaux marchés, nouveaux produits…) sont en adéquation, vous avez atteint le seuil de décision.

Migrer ou ne pas migrer ?

Comme l’écrivait Shakespeare dans Hamlet, Prince du Danemark, telle est bien la question. Avoir atteint le seuil de décision est bien, prendre la décision est mieux. Seule l’étude de faisabilité permet de répondre à la question « Migrer ou ne pas migrer ». La décision est prise en connaissance de cause puisque l’étude de faisabilité est une phase en amont du projet de migration qui ne doit pas être ni négligée ni mise de côté et doit permettre de connaître tous les tenants et aboutissants du projet de migration lorsque celui-ci débutera. Cette analyse de faisabilité nous permet de comprendre l’investissement, de maîtriser les coûts et de réduire les risques.

Cette phase de collecte d’informations permet de définir les objectifs et priorités du projet. Elle peut se décliner en plusieurs volets : technique, métier, environnemental…et tout autre sujet incontournable du domaine impacté par la migration. La conduite de l’analyse de faisabilité peut se faire par interview ou par l’utilisation d’outils dédiés suivant le volet.

Le volet métier, pour la migration d’une application, permet de comprendre :

-          La pérennité de l’application,

-          La criticité de l’application ou des données manipulées par l’application,

-          L’interaction avec les acteurs externes (utilisateurs, autres systèmes…),

-          Les règles métier impactées,

-          Le rôle de l’application dans le business global de l’entreprise.

Le volet technique doit permettre de comprendre la complexité technique et quantifier finement le périmètre de la migration. Par exemple dans le cadre de la migration d’une application, l’évaluation technique donnera les mesures telles que le nombre de lignes de code, le nombre de fichiers source, les dépendances, les diagrammes, etc.

Enfin, l’évaluation de l’environnement permet de comprendre l’impact de la migration sur les outils, les personnes et les méthodologies, comme par exemple l’environnement de développement, les compétences des personnes chargées d’effectuer la migration ou la reprise post-migration, etc.

Scenarii de migration

Afin de faire une estimation de charge du projet de migration, il est nécessaire d’évaluer les différents scenarii de migration possibles. En général, un scénario global est retenu mais les sous-parties d’un projet de migration peuvent être adressées avec des scenarii différents du scénario global.

Les 4 scenarii de migration :

-          Portage

-          Réutilisation

-          Réécriture

-          Remplacement

Le portage est propice lorsque le besoin fonctionnel n’est pas remis en cause, que les modifications à apporter sont modérées et qu’il est nécessaire d’apporter de nouvelles fonctionnalités. Dans ce scénario, ce sont généralement les coûts de maintenance/production ou des raisons stratégiques (ouverture vers les nouvelles technologies) qui représentent les facteurs de migration prépondérants. Le portage est le principe selon lequel l’existant sera porté d’une technologie X à une technologie Y, en général pour bénéficier des avantages de la technologie Y non présents dans la technologie X.

La réutilisation est considérée lorsque le fonctionnel est satisfaisant ou que les coûts sont relativement faibles. Dans le cas d’une application, il peut s’agir aussi d’une mauvaise séparation des couches applicatives, ce qui peut-être subi plutôt que choisi. La réutilisation, lorsqu’elle est techniquement possible, induit généralement un investissement minimal et permet d’accéder rapidement aux fonctionnalités de la nouvelle plateforme technologique. Bien que séduisante, la réutilisation peut engendrer des effets de bord ou des dégradations de service qui sont généralement dus à la technologie ou la conception initiale ne répondant plus aux principes que les nouvelles technologies (imaginer que migrer simplement une application client/serveur vers du Web peut se faire par réutilisation est généralement une utopie).

La réécriture est envisagée lorsque les indicateurs sur les règles métier, le fonctionnel, la qualité, etc. sont au rouge. En effet, à quoi sert de migrer une application de mauvaise qualité ou dont les coûts de maintenance sont élevés pour obtenir une application basée sur les nouvelles technologies mais trainants de graves problèmes de conception ? En général, la réécriture est le scénario pour lequel l’investissement est le plus important (mais ce n’est pas toujours vrai d’où la nécessité absolue d’une étude de faisabilité) mais il a l’avantage, pour l’architecte, de repartir à 0 en bénéficiant des nouvelles façons de faire (conception, design patterns…) plus évoluées et plus adaptées.

Le remplacement est étudié dans le cas où l’application ne répond plus aux besoins métier de l’entreprise. Plus généralement, ce scénario est utilisé sur des parties d’un système ayant bénéficié d’apports tiers externes comme un composant graphique d’un éditeur de logiciels tiers par exemple. Le remplacement peut avoir un effet « boule de neige » car les dépendances de l’application, système ou module à remplacer peuvent impacter au-delà du périmètre d’un lot de migration ou du projet complet (exemple : remplacer Oracle par SQL Serveur).

Retrouvez cette première partie au travers d'un web cast:

Stratégies et enjeux de la migration vers .Net

L’analyse de faisabilité

Comme nous l’avons déjà mentionné, l’analyse de faisabilité doit permettre de prendre la décision de migrer ou ne pas migrer en connaissance de cause. Cette étape incontournable est la première de tout projet de migration et fait parti du plan projet. L’investissement réalisé sur cette phase peut conduire à la conclusion de ne pas migrer, et peut être considéré comme perdu. Malgré tout la prise de décision ne doit pas se faire sans cet investissement minimum. De plus, il est très difficile d’estimer le temps de l’analyse (et donc l’investissement initial) étant donné qu’il est dépendant de beaucoup d’inconnus. En conclusion, l’analyse de faisabilité ne répond pas réellement à migrer ou ne pas migrer mais plutôt à comment et que migrer. Pour cette raison, la décision de migrer doit reposer sur des facteurs opportuns et résultants suffisamment forts pour que la décision de migrer soit une décision stratégique prise en amont de l’étude de faisabilité par les décideurs influents ou sponsors. De toute façon, il faut toujours envisager de migrer un jour ou l’autre et donc l’investissement réalisé dans l’analyse de faisabilité n’est jamais perdu.

L’analyse de faisabilité doit permettre de faire les bons choix pour le projet de migration (objectifs & priorités) :

-          Analyse de l’architecture existante et cible

-          Inventaire à migrer (y compris les tests ou l’environnement de test)

-          Mesures, indicateurs…

-          Problèmes à anticiper pendant la migration

-          Estimation de temps et de coûts pour la migration

-          Scenarii de migration

L’analyse de faisabilité sur un ensemble de systèmes (ou applications) permet d’ordonnancer la migration. Pour cela, il est possible de servir d’un quadrant de migration tel que celui présenté ci-dessous :

Le processus de migration

Le processus de migration dépend en partie des technologies en jeu. Malgré tout, les grandes phases d’un projet de migration sont récurrentes et c’est d’ailleurs l’industrialisation de ces phases qui permet de mettre en place l’usine à migration. L’étude de faisabilité fait parti d’une phase de planification plus globale identique à un projet classique.

La planification définit les éléments suivants :

-          Définition des objectifs de la migration (exemple : amélioration de la performance)

-          Définition des attendus (exemple : l’application doit calculer 5 fois plus vite)

-          Définition des contraintes (exemple : à configuration matérielle équivalente)

-          Evaluation des risques

-          Planification des tâches ; Ordre de migration des modules de l’application

-          Prototype de migration (si possible) permettant de détecter les problèmes aux plus tôt, de se familiariser avec les technologies et de commencer par un projet simple.

La planification des tâches, comme dans tout projet, permet d’ordonner les étapes spécifiques du projet de migration, à savoir :

-          Définition du périmètre projet

o   Composants & fonctionnalités à migrer

o   Objectifs de la migration

o   Analyse de l’application

o   Evaluation des architectures existante et future

o   Analyse et conception des nouvelles fonctionnalités

o   Choix de la stratégie de migration (totale ou par étapes, horizontale ou verticale si applicable)

o   Inventaire

-          Préparation

-          Migration

-          Tests

-          Valider l’équivalence fonctionnelle

-          Ajout & test des nouvelles fonctionnalités

-          Déploiement

La préparation consiste à se mettre dans les meilleures conditions avant le lancement de la migration. Cette étape optionnelle permet d’améliorer l’efficacité de la migration. Lorsque le seuil de migrabilité est atteint (seuil optimum pour la migration), la phase de migration est enclenchée.

Dans toutes les étapes du projet de migration, il convient d’utiliser les bons outils et de capitaliser sur l’expérience des projets migrés.

Les bonnes pratiques

Les bonnes pratiques listées ci-dessous sont issues de différents projets de migration et peuvent servir de guide le cas échéant.

-          Un projet de migration est prioritaire ; C’est aussi parmi les projets les plus complexes.

-          Migrer dans les conditions favorables de migrabilité (base stable, peu d’évolutions…)

-          Commencer par une application critique pour le métier mais faiblement complexe techniquement : un projet de migration réussi est très motivant pour la suite et démontre la capacité à faire évoluer l’existant.

-          Mixer les équipes avec les personnes ayant une bonne connaissance du fonctionnelle et d’autres ayant une bonne connaissance des technologies cibles ; Créer une osmose de manière à amener les fonctionnels sur les nouvelles technologies et les experts technologiques au fonctionnel.

Usines à migration

Le premier type d’usine à migration spécifiée est l’usine à migration de Visual Basic 6.0 vers .NET. D’autres usines à migration définies par le Microsoft Technology Center de Paris vont continuer à apparaître sur les technologies suivantes :

-          PHP vers ASP.NET

-          FoxPro vers .NET

-          Java vers .NET

-          Oracle Forms vers .NET

-          Delphi vers .NET

Pour tout renseignement ou information, prenez contact avec le MTC Paris : mtcparis@microsoft.com ou directement avec Frédéric Queudret (Architecte MTC) : fredeq@microsoft.com.

L’usine à migration de Visual Basic 6.0 vers .NET

Références

-     Interview sur l'atelier d'étude de faisabilité: http://www.microsoft.com/france/msdn/vbasic/migration/atelier-de-migration-de-vb6-a-vbnet.mspx 

-          Processus de mise à niveau de WSS 2.0 à 3.0 : http://blogs.msdn.com/fredeq/pages/article-sur-le-processus-de-mise-niveau-et-migration-de-wss-2-0-3-0.aspx

-          Convert a Java Web Application to ASP.NET using JLCA : http://msdn.microsoft.com/msdnmag/issues/07/05/Migration/

-          Mise en œuvre d’une stratégie de migration de Visual Basic 6.0 vers Visual Basic .NET : http://www.microsoft.com/france/msdn/vbasic/ressources/appmigrationstrat.mspx

La solution est téléchargeable en pièce jointe de cet article (voir à la fin). 

Ci-dessous un exemple de style appliqué à un bouton :

<Window x:Class="StyledWinApp.Window1"

    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"

    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"

    Title="StyledWinApp" Height="300" Width="300"

    >

  <Window.Resources>

    <Style x:Key="BasicButtonStyle" TargetType="Button">

      <Setter Property="Control.Background" Value="LightBlue"/>     

    </Style>

  </Window.Resources>

    <Grid>

      <Button Content="Hello!" Style="{StaticResource BasicButtonStyle}">       

      </Button>

    </Grid>

</Window>

Dans la suite de l’article, j’utiliserai un style AquaGel dont la démonstration est téléchargeable ici : http://www.valil.com/AquaGelButton.zip sur le blog de Valentin Iliescu.

Dans un premier temps, nous allons créer un projet de type « Custom Control Library (WPF) » (nommé MTCParis.WPF.Themes.AquaGel pour l’exemple). Dans ce projet, il n’est pas nécessaire de conserver le contrôle utilisateur créé par défaut. Il convient d’ajouter un nouvel élément au projet de type ResourceDictionary (WPF). La déclaration du template du contrôle bouton est copiée puis collée dans le fichier XAML nouvellement créé que j’ai nommé AquaGelButtonStyle.xaml pour la démonstration. J’ai ajouté une déclaration d’un style encapsulant la déclaration du template.

<Style x:Key="AquaGelButtonTemplateStyle" TargetType="{x:Type Button}">

    <Setter Property="Template" Value="{DynamicResource AquaGelButtonTemplate}" />

  </Style>

Dans la démonstration téléchargée, chacun des 3 boutons est ensuite stylé avec différente couleur (bleu, rouge, jaune). Dans l’exemple d’externalisation et de réutilisation des ressources, je vais spécialiser un style pour le bouton rouge afin qu’il soit réutilisable simplement sur différentes applications de la manière suivante (remarquez l’attribut BasedOn qui permet d’hériter d’un autre style):

<Style x:Key="RedAquaGelButtonTemplateStyle" TargetType="{x:Type Button}" BasedOn="{StaticResource AquaGelButtonTemplateStyle}">

      <Setter Property="Background">

        <Setter.Value>

          <LinearGradientBrush StartPoint="0,0.5" EndPoint="1,0.5">

            <LinearGradientBrush.RelativeTransform>

              <TransformGroup>

                <TranslateTransform X="-0.5" Y="-0.5"/>

                <ScaleTransform ScaleX="1" ScaleY="1"/>

                <SkewTransform AngleX="0" AngleY="0"/>

                <RotateTransform Angle="90"/>

                <TranslateTransform X="0.5" Y="0.5"/>

                <TranslateTransform X="0" Y="0"/>

              </TransformGroup>

            </LinearGradientBrush.RelativeTransform>

            <LinearGradientBrush.GradientStops>

              <GradientStopCollection>

                <GradientStop Color="sc#1, 0.5, 0, 0" Offset="0"/>

                <GradientStop Color="sc#1, 1, 0.5, 0.5" Offset="1"/>

              </GradientStopCollection>

            </LinearGradientBrush.GradientStops>

          </LinearGradientBrush>

        </Setter.Value>

      </Setter>

    </Style>

 Afin que le dictionnaire de ressources de l’assembly satellite soit utilisable depuis une application, il est nécessaire d’indiquer un nom de classe que nous pourrons référencer. Cela se fait dans l’en-tête déclaratif du dictionnaire de ressource :

x:Class="MTCParis.WPF.Themes.AquaGel.AquaGelButtonResource"

Puis ajouter la déclaration partielle de la classe avec un constructeur qui effectue la phase d’initialisation (Ajouter une nouvelle classe du même nom dans le projet) :

namespace MTCParis.WPF.Themes.AquaGel

{

    public partial class AquaGelButtonResource

    {

        public AquaGelButtonResource()

        {

            this.InitializeComponent();

        }

    }

}

Revenons maintenant à une application dans laquelle nous souhaitons utiliser notre librairie de style. La première étape est de référencer l’assembly satellite. Ensuite nous devons ajouter le code de chargement de la librairie et de fusion des ressources avec les ressources existantes de l’application. Je surcharge pour cela l’événement OnStartup dans le code du fichier de démarrage (App.xaml) :

protected override void OnStartup(StartupEventArgs e)

{

    base.OnStartup(e);

}

Puis, nous fusionnons le dictionnaire de ressources de l’assembly satellite aux ressources de l’application :

protected override void OnStartup(StartupEventArgs e)

{

   base.OnStartup(e);

   this.Resources.MergedDictionaries.Add(new MTCParis.WPF.Themes.AquaGel.AquaGelButtonResource());

}

Il reste à spécifier le style à utiliser sur le contrôle cible comme le montre l’exemple ci-dessous :

<Button VerticalAlignment="Top" Margin="179.5,171.4,385.5,0" Width="Auto" Height="40"

   x:Name="Button1"

   Style="{DynamicResource RedAquaGelButtonTemplateStyle}"

   RenderTransformOrigin="0.5,0.5" Content="Button1">

Il est possible de decliner les autres styles (vert et jaune ou bleu) de la même manière dans l’assembly satellite.

Ci-dessous un exemple avec la déclaration du style dans le contrôle Button1:

Après l'application du style:

Cette externalisation permet d’isoler la déclaration des styles et améliorer leur réutilisabilité. Il nous vous reste plus qu’à créer vos propres librairies de styles réutilisables et à les publier J !

ExternalStyleSolution.zip

Les CTP de Visual Studio Express Codename « Orcas » sont maintenant disponibles en téléchargement sur le site MSDN : Community Technology Preview of the Visual Studio Express.

Beaucoup de nouveautés dans ces versions :

·         Full support for the .NET Framework 3.5 including LINQ to SQL, LINQ to Entities and LINQ to XML

·         DLINQ Designer

·         WPF Designer  (codename “Cider”) and XAML editor

·         Integrated support for SQL Server Compact Edition

Get the latest downloads for Windows Vista, .NET Framework 3.0, and Windows SDK.

Sorti en 1995, Borland Delphi offre depuis de nombreuses années un puissant outil de développement d’applications Windows.
Depuis 2002, la plateforme de développement Microsoft s’oriente vers une nouvelle technologie : .Net. Ne remettant évidemment pas en cause le développement natif (non .Net), Microsoft offre donc aujourd’hui le choix entre deux technologies.

Migrer vers .Net ? Conserver le langage de développement Pascal Objet ? Récupérer le code existant ? Faire cohabiter du code natif et .Net ? Partager l’expérience avec des entreprises qui ont passé le cap ? Autant de questions sur lesquelles Mitsu Furuta vous propose de débattre le mercredi 18 avril 2007, au 148 rue de l’Université à Paris.

Notre but est de débattre sur le sujet et de comprendre comment Microsoft peut vous aider à appréhender ces nouveaux enjeux.

Le séminaire se terminera par une courte présentation de l'activité du MTC autour des sujets de migration et notamment les possibilités offertes aux clients pour étudier la faisabilité de la migration de leurs applications Delphi vers .NET. Cliquez ici pour vous inscrire.