• Structurer les développements suivant les normes, les méthodes & l'architecture logicielle en vigueur.
  La plate-forme d'industrialisation doit proposer un FrameWork (si le client n'en possède pas), soit être capable d'intégrer tout FrameWork existant (le client possède déjà le sien).
• Permettre la création de l'application spécifiée en minimisant (voir en annulant) les efforts de coding dans le langage cible.
  Pour cela, deux moyens sont possibles :
  • Générer le code applicatif à partir des spécifications fournies en entrée.
  • Designer l'application à travers un outil RAD, si possible en reprenant les travaux de maquettage qui ont pu être faits dans le cadre de la phase de spécification.
  Ces deux voies doivent d'ailleurs être complémentaires.
  En effet, même si de plus en plus de clients ont adopté la modélisation UML pour spécifier leurs applications, il n'en demeure pas moins vrai que si c'est bien le cas pour la description du processus métier, des règles de gestion & des données, la description des IHM se fait à travers la réalisation de maquettes (Plus visuelles – Moins conceptuelles – etc.).
  Par ailleurs, il reste certains clients qui sont réfractaires à l'idée de modélisation (Délai de spécification – Difficulté de validation de la part des utilisateurs – etc.) et qui préfèrent rester sur une expression des besoins littéraire et utiliser un outil de développement « facilitateur ».
• Permettre les tests unitaires des composants applicatifs,
• Produire la documentation associée,
• Gérer en versions les codes produits,
• Contrôler la qualité logicielle,
• Permettre l'automatisation des déploiements sur les environnements d'intégration, de recette voire de production.

• L'atelier : Il s'agit ici d'un véritable berceau capable d'intégrer l'ensemble des outils constituant l'atelier
• Le Designer : C'est un outil qui permet de designer l'application à réaliser. Il propose de le faire de deux façons :
• A travers la modélisation : Aujourd'hui le langage de modélisation reconnu est UML (Unified Modeling Language). Cet outil doit donc permettre de décrire sous forme graphique les applications. Il doit par ailleurs proposer des imports (intégration de modélisations existantes) & exports de fichiers au format standard XMI & se présenter sous forme de PlugIn vis à vis de l'atelier projet.
• En mode RAD : Il s'agit ici de décrire les applications grâce à des interfaces utilisateur évitant le coding. Pour cela il présente trois types d'interfaces :
  • Designer : Il permet de construire l'élément de l'application sans coding & si possible sans se préoccuper de la cible technologique. Il s'agira d'un Designer par assemblage d'objets sur un gabarit pour les IHM, Graphique du type ordinogramme pour la description des événements, l'appel des services métiers & le contrôle des résultats & des saisies, Wizard pour les objets métiers & de persistance.
  • Prévisualisation : Il s'agit ici de présenter le résultat du design dans la cible technologique. Cette prévisualisation est pertinente dans le cadre des IHM (équivalent Maquette), mais on peut imaginer une prévisualisation de la dynamique applicative (présentation de l'IHM, activation d'un événement & visualisation du résultat).
  • Editeur de code : Il s'agit ici de présenter les sources produit par les designer pour pouvoir les modifier. Bien évidemment, le DESIGNER doit prendre en compte les modifications « codées ».
  Il doit également permettre de récupérer en entrée les maquettes ou les sources existants & d'intégrer les fonctionnalités d'un FrameWork.
• Le générateur de code : Il intègre les spécifications fournies en entrée (dans notre cas, il s'agit des conceptions UML) indépendamment du profil d'analyse (pour cela, il propose une interface d'intégration des spécifications en interprétant les règles d'analyse fournies en paramétrage) et les transforme en sources & documentations correspondant à la cible technologique & au FrameWork à utiliser.
  Par ailleurs, il échange des données (synchronisation entre les développements par génération & par RAD) avec l'atelier RAD. Ce qui est produit par le générateur doit être visible dans le Designer & inversement.
• Le FrameWork : Il implémente les :
• couches techniques de l'architecture logicielle en respect des design pattern MVC (Couche Navigation & Contrôle), BO (Métier) & DAO (Persistance)
• couches de services techniques génériques (Authentification – Habilitation - Gestion des erreurs – Gestion des log applicatifs – Gestion de la session & de son contexte – Gestion des tests unitaires – L'internationalisation des applications - etc.)
• bibliothèques d'outils facilitant le développement (Objets de présentation complexes ou composites – Gestion des événements clients – Gestion des contrôles de saisie – Formatage des données – etc.)
• des composants métiers génériques (WorkFlow – Identification – Recherche multi-critère – etc.)
• Le gestionnaire de version : Il gère les versions du FrameWork, des sources générés ou écrits et des documentations associées. Il est piloté par le Designer.
• L'outil d'assurance qualité : Son rôle est de :
• proposer un modèle de projet (que l'on appelle aussi une Application Blanche ou encore BlankApp)
• contrôler que les codes produits :
• respectent bien les normes & méthodes en vigueur (Utilisation du FrameWork – Respect des règles de nommage – Non duplication de code – etc.)
• ont été testés unitairement,
• etc.
• de gérer les bugs (description – suivi – construction de patch – etc.)
• de gérer les demandes d'évolution & de changement
• de proposer des reports (résultat de tests d'assurance qualité – Etats des bugs ou des demandes – etc.)
• L'outil d'intégration : Son rôle est :
• d'automatiser les procédures d'intégration à savoir :
  • de créer les scripts de déploiement des composants applicatifs
  • d'assurer à la demande :
  • les compilations des codes sur la cible technologique de production
  • le déploiement des composants sur les plates-formes cibles suivant les scripts de déploiement.
  cela pour une version d'application donnée.
• de permettre l'accès aux ressources externes du projet, principalement les bases de données,
• de déployer et lancer (notamment le serveur d'application) sur un environnement local l'application en cours de réalisation

• JAVA :
• RSA de IBM : le plus complet (Il intègre un éditeur puissant , un outil de modélisation & son générateur de code, un gestionnaire de version, un outil d'intégration & de tests unitaire, etc.) mais c'est le plus lourd (2Go de RAM est ici fortement recommandé si vous ne voulez pas passer votre temps à attendre), le plus coûteux (et pas seulement au niveau de la licence, mais de l'expertise nécessaire notamment pour son générateur de code).
• Jbuilder X de Borland : Il ne lui manque que le générateur de code.
• Sun One Studio de SUN : Il lui manque un outil de modélisation & donc un générateur de code. Par contre, la possibilité d'intégrer des nouvelles fonctionnalités à travers de PlugIn (c'est le même principe que pour Eclipse) permet d'intégrer les manques comme par exemple un outil de modélisation (MagicDraw de NoMagic ou SDE de Visual Paradigm) & que les éditeurs ou la communauté ne tarderons pas à proposer des générateurs de code pour cette plate-forme.
• MyEclipseIDE de MyEclipseIDE.com : C'est en fait une distribution de ECLIPSE intégrant tous les PlugIn OpenSource les plus efficaces (Distribution de « base » à environ 35 € par poste de travail et par an), complété de PlugIn « commerciaux » (Version « WorkBench » dont le prix n'est pas communiqué). Le site annonce l'arrivée prochaine d'un outil de conception & de son générateur de code pour le « WorkBench ».
• NitroX de M7 : C'est un distribution Eclipse intégrant tout comme MyEclipseIDE un ensemble de plugIn Eclipse Open Source facilitant les tâches périphériques aux coding, complété de PlugIn « commerciaux » composé d'un Designer de JSP, de JSF, de STRUTS & TILES.
• .NET :
• VisualStudio .Net de MicroSoft : C'est bien évidemment la référence dans le monde .NET & intègre l'ensemble des fonctionnalités d'une plate-forme d'industrialisation des développements.

Olivier HEDIN