vendredi 29 août 2008

ROSARIO : Module Développeurs

La nouvelle version Team Developer de Rosario apporte elle aussi sa part de nouveautés qui vont permettre au développeur un contrôle plus efficace concernant la qualité du code écrit au travers de nouveaux outils dont :

  • Le Standalone Debugger
  • Le History Debugger
  • La gestion des tests unitaires impactés.
  • La gestion de l'analyse statique de code par groupe de règles paramétrables.
Le Standalone Debugger : Zero Impact Debugging
Ce nouvel outil a pour vocation de permettre à un développeur d'effectuer des opérations de débogage sur une machine cible (pré-production, intégration ou test) sans avoir à installer Visual Studio. Cet outil est simplement généré à partir de la station de développeur sous forme d'un ensemble de fichiers et est simplement déployable suivant une procédure XCopy.

L'outil pourra donc être utilisé soit :
  • à partir d'une clé usb.
  • à partir d'un share réseau.
  • en copiant les fichiers sur la machine cible.
La taille de l'outil généré est de moins de 50 Mo!
Ci dessous les étapes pour générer un Standalone Debugger puis le mettre en oeuvre :

A partir de visual Studio lancer la commande Debug / Create Standalone Debugger

L'assistant suivant démarre, spécifier l'emplacement disque pour la création de l'outil (dossier, clé usb ou encore partage réseau :

Cliquer sur Suivant, le processus de génération est lancé :

Cliquer sur Finish pour finaliser le processus

Si l'on ouvre le dossier cible, on constate la création des binaires de l'outil sous forme de différents exécutables, assemblies et fichiers :

Pour démarrer le Standalone Debugger, il suffit de double cliquer sur le fichier Vsdebug.exe. L'interface graphique se présente comme illustré ci dessous et affiche une page d'accueil permettant de démarrer rapidement sans consulter de fichiers d'aide :

Les taches tels que démarrer un programme, s'attacher à un process, ouvrir un fichier ou une solution sont disponibles directement à partir de la page d'accueil.
Pour démontrer la puissance de cet outil nous allons effectuer une petite démonstration édifiante :
Créons une petite application Winform avec comme unique fonction un bouton affichant une message box.
Déployons cette application sur une station cliente (attention, le fichier pdb doit être présent sur la machine cible). Ci dessous le contenu du dossier de cette application :

Le développeur doit déboguer l'application sur cette station et va donc générer une instance de l'outil sur sa clé usb ainsi qu'une copie des fichiers C# à déboguer, dans notre exemple, il s'agit du fichier form1.cs par exemple.

Etape 1 : Démarrage de l'application sur la machine cible

Etape 2 : Démarrer le Standalone Debugger à partir de la clé USB en cliquant sur VSDebug.exe

Etape 3 : A partir de la page d'accueil du Debugger cliquer sur le lien Attach : Process




Etape 4 : Selectionner le processus de l'application à déboguer puis valider

Etape 5 : A partir de la clé usb ouvrir le fichier form1.cs et placer un point d'arrêt sur l'évènement on_click du bouton



Etape 6 : Le clic sur le bouton "demo" de l'application active le point d'arrêt (mode Debug) comme si le développeur utilisait Visual Studio directement sur son poste de développement.

Il est évident que cette nouvelle fonctionnalité va grandement aider à la résolution des bugs et notamment réduire le fameux syndrome de non reproductibilité des bugs. Le développeur a à sa disposition un outil lui permettant de diagnostiquer de manière efficace les anomalies d'une application directement sur les plates formes cibles réduisant ainsi considérablement les temps d'investigation pour la résolution de bugs

L'History Debugger : Trouver et fixer rapidement un bug (Nom de code Proteus)
L'history Debugger est une nouvelle experience F5 pour le développeur , ce nouvel outil intégré à Visual Studio for Developer Edition enregistre l'ensemble des artefacts produits durant l'exécution d'une application en mode debug et permet de retracer ou rejouer l'execution :
En cas de Bug, il est très simple et rapide de trouver la cause simplement en consultant les information recueillies par l'outil présentées sous la forme d'une structure arborescente.
L'outil augmente la productivité du développeur en réduisant le temps d'investigation sur la cause d'une erreur dans le code ou sa reproduction.
Regardons le fonctionnement de l'outil à travers une démonstration :
Pour cette démonstration nous allons utiliser l'application Patient Monitoring, application de démonstration écrite en WPF fournie avec la VPC Rosario (CTP d'Avril.).
Pour ce scénario de Debug, on démarre l'application à partir de la solution dans Visual Studio en pressant la touche F5

L'application Patient Monitoring s'affiche

Sur activation de l'onglet Details, la photo du patient apparait ainsi que des informations détaillées

Le développeur choisit alors le patient "Aaberg" et constate que pour ce patient, la photo n'apparait pas :


Le développeur va alors lancer à partir du menu Debug / Windows la commande Debug History pour accèder à l'historique des actions effectuées durant la session de debug :

La fenêtre apparait comme illustré ci dessous :

Le développeur clique sur le lien "Break into the Debugger", affichant ainsi l'historique de l'ensemble des évènements survenus lors de la phase de debug sour forme d'une arborescence :

On remarquera l'iconographie placé devant les noeuds de la treeview, et notamment les symboles d'erreurs en rouge, indiquant les erreurs levées lors de l'exécution. Dans notre cas, on remarque que le chargement de l'image du patient a déclenché une erreur qui a été gérée, raison pour laquelle l'application n'a pas planté.
Le développeur va donc pouvoir rapidement corriger l'anomalie en consultant simplement les informations fournies en regard de l'icone Erreur : le message est "cannot locate ressource ..."

Le nouvel outil History Debugger permet également au développeur de naviguer dans le scénario de debug simplement en cliquant sur les noeuds de l'arborescence avec la possibilité par un simple double clic d'afficher le code concerné par l'action enregistrée.
Il est incontestable que cet outil sera d'une aide précieuse au développeur pour l'activité de Bug fixing.
L'outil fonctionne comme un recorder durant les phases de Debug, le niveau d'informations est d'ailleurs paramétrable comme le montre la capture d'écran ci dessous :


Paramétrage de l'outil History Debugger

La gestion des tests unitaires impactés

Il est aujourd'hui largement établi que la qualité d'un développement passe par l'activité de test et que le métier de développeur est bien évidemment d'écrire du code mais surtout de vérifier que le code écrit fonctionne.
A ce titre Le message de Microsoft au travers l'implémentation du module Team Tester est clair : "Du code qui n'a pas été testé ne doit pas être livré!".
Dans les versions précédentes de Visual Studio (2005 et 2008), sur la partie tests unitaires, l'outil permet de générer l'ossature des tests unitaires pour l'ensemble des fonctions écrites dans un projet en quelques clics de souris. Néanmoins, sur des projets de taille importante le développeur se trouve très rapidement en face de centaines de tests unitaires à gérer et dans l'incapacité de savoir pour une modification de code donnée quel test unitaire est impacté. Compte tenu des temps d'exécution des test unitaires, le fait de rejouer l'intégralité est couteux en temps.
C'est exactement à cette problématique que répond la nouvelle version de l'outil : Afficher les tests unitaires impactés par une modificaiton de code.
Regardons dans la pratique à travers un exemple comment cette nouvelle fonctionnalité est implémentée dans l'outil.
Pour gérer les test unitaires impactés, le développeur doit tout d'abord afficher la nouvelle version de la fenêtre "Test View" en lançant la commande Test / Other Windows / Test View.

La fenêtre apparait à priori identique à celle de la version 2008


Le développeur active la fonction Group By en choisissant la nouvelle option "Test Impact Status"

La fenêtre affiche l'ensemble des tests dans la rubrique "Not Impacted"

Le développeur effectue alors des modifications dans le code de son application, (dans notre exemple, 2 lignes de code) puis sauvegarde ses modifications.

Aussitot l'outil detecte les tests unitaires qui ont été impactés par les modifications de code et affichent les tests unitaires impactés dans la rubrique "recommended", ce qui indique au développeur qu'il est recommandé de rejouer ces tests afin de vérifier l'impact des modifications afin d'éviter de potentielles régressions.

Le développeur procède à l'éxécution des tests impactés en utilisatnt le menu contextuel à partir de la fenêtre "Test View".

Lorsque les tests sont rejoués, ils apparaissent dans la rubrique "Verified"

La fenètre sera remise à jour au fur et à mesure des modifications apportées. Le développeur a donc en permanence une vision de l'impact de ses modifications sur la stabilité de l'application au travers des tests unitaires.

La gestion de l'analyse statique de code par groupe de règles paramétrables

Suivant l'adage bien connu "Trop d'information tue l'information", voici une nouvelle fonctionnalité qui va améliorer le contrôle et le focus du développeur sur la mise en conformité de son code par rapport aux règles appliquées par l'outil d'analyse statique de code fourni avec Visual Studio FXCop (206 règles réparties dans 11 groupes : Design, Globalisation, intéropérabilité, maintenabilité, mobilité, Nommage, Performance, Portabilité, Stabilité, Sécurité et Usage). Dans les versions précédentes, le nombre d'erreurs et de warnings générés par cet outil décourageait rapidement les développeurs pourtant plein de bonne intention au départ. Grace à la nouvelle version de l'outil, il est maintenant possible de simplement Créer des groupes de règles en fonction de critères pertinents par rapport à un contexte projet puis choisir les groupes de règles à appliquer. Cela agit comme un filtre qui va permettre de cibler le travail du développeur. Au travers d'un scenario, nous allons voir comment tirer profit de cette nouvelle fonctionnalité. Lançons tout d'abord une analyse de code statique sur un des projets de notre solution en utilisant la commande "Run Code Analysis" du menu contextuel :

Le résultat de l'analyse laisse apparaitre 18 warnings :

Nous allons modifier le paramétrage en utilisant les groupes de règles paramétrables. Pour cela, il suffit d'ouvrir la fenêtre de propriétés du projet et activer l'onglet "Code Analysis" comme indiqué ci dessous :

On remarque que la configuration en cours est "All Rules" et entraine l'applicaiton des 206 règles.Hors en supposant que la livraison d'une release est proche, nous allons sélectionner l'option "Release Criteria CheckList" dans la liste Rule Set. Instantanément, le nombre de règles tombe à 48, ce qui va fortement limiter le nombre de warnings à traiter par le développeur.

Le développeur relance une analyse sur le projet, le nombre de warning est tombé de 18 à 5

Le développeur ou le responsable projet pourra également créer des règles customs et les exporter sous forme de fichiers XML afin de les distribuer à l'équipe de développement.
Dans ce dernier exemple, on personnalise une règle Custom pour n'adresser que les violations concernant les performances.


En relançant l'analyse, le développeur a isolé les warnings concernant les règles de performances.

Encore une innovation qui va contribuer à la qualité des développements, à disposition des développeurs pour une travail avec plus de productivité.

mardi 26 août 2008

ROSARIO : Module Architecte

Dans cet article nous allons nous interesser aux nouveautés du module Team Architect de Rosario qui font de ce module aujourd'hui un outil incontournable et indispensable non seulement dans le design d'applications mais également dans la découverte d'architectures existantes dans le cadre par exemple de missions d'audit qualité ou encore de TMA voire même comme outil d'estimation.

Les versions actuelles de TFS (2005 et 2008) proposent des schémas basés sur la technologie des DSL (Domain Specific Language) pour produire des schémas d'architecture. Les types de schémas proposés sont les suivants :

  • Application Designer Diagram
  • Logical Datacenter Designer Diagram
  • System Designer Diagram
  • Deployment Designer Diagram
  • Class Designer Diagram
Avec ces DSL spécifiques aux architectes, on décrit dans un langage qui est d'un peu plus bas niveau que ce que fait l'UML, donc un langage un peu plus précis (notamment pour le Class Designer entièrement compatible avec les Types .Net : toute modification dans un schéma est automatiquement répercutée dans le code et vice versa).
Avec ROSARIO Team Architect, Microsoft va encore plus loin en se fixant les objectifs suivants :
  • Gérer la complexité à l'aide de modèles visuels
  • Comprendre, Manipuler et faire évoluer des applications existantes.
  • Améliorer la maintenabilité, la modularité et la réutilisation de composants des applications.
Pour atteindre ces objectifs, les fonctionnalités suivantes ont été implémentées :

Modélisation Logique et physique intégrée : Avec Rosarion Microsoft décide d'intégrer enfin UML au niveau Logique et conserve DSL au niveau physique. UML devient le langage de modélisation privilégié dans Rosario et fonctionne à la fois en mode génération et rétro-conception.
Module Architecture Explorer : Pour découvrir une architecture existante, la comprendre, manupuler et réutiliser l'existant, ce nouvel outil devient le point d'entrée pour comprendre et interagir avec une architecture logiciel. Indubitablement le nouveau couteau Suisse des architectes.
Intégration de Software Factories : Issu des travaux conjoints entre les équipes de Rosario et de Patterns & Practices (WSSF) la migration de la software Factory vers Rosario vient enridhir le modèle de conception d'applications du modèle architecte et va permettre par exemple d'ajouter des services WCFs avec la génération du host, de l'implémentation et des contrats. Ce module s'appuiera evidemment sur GAX (Guidance Automation Execution Engine) et GAT (Guidance Automation Toolkit)
Nous allons détailler le contenu de ces innovations dans les paragraphes suivants en commençant par le module Architecture Explorer.

L'outil Architecture Explorer : le couteau suisse des architectes
La première grande nouveauté de ce module Rosario Team Architect est le tout nouvel outil : Architecture Explorer.
Cette toute nouvelle interface WPF est un Module de découverte d'architecture permettant d'explorer une architecture existante en partant des Team Projects ou des solutions vers les projets, classes, méthodes, évènements, métriques de code, Work Items, Diagrammes d'architectures, etc. en utilisant les relations de dépendances entre ces objets. L'outil permet également par un simple double clic d'accèder à l'objet selectionné et donc par exemple au code d'un classe ou d'une méthode.
Ce dessous, un aperçu de ce nouvel outil :

Si l'on y regarde de plus près, on s'aperçoit que pour chaque objet (Team Project, Solution, projet, classes...) on peut sélectionner des objets appartenant ou appelés par les objet parents à l'aide de listes filtrées. La capture ci dessus nous montre une navigation avec un profondeur de 7 niveaux, mais on peut avoir bien plus de niveaux selon les objets explorés.
L'outil permet également de lancer des actions sur ces objets tel que l'insertion de l'objet dans un diagramme UML, le calcul de métriques de code, la création d'un Work Item et bien d'autres encore.
Juste au dessous des listes de filtrage, une surface de design permet également de visualiser en temps réel le statut des éléments selectionnée ainsi que leurs relations.
Différentes vues sont dispobibles, à commencer par une vue en arborescence horizontale ou verticale au choix, avec les relations entre les objets selectionnés. Dans l'exemple ci dessous, on a selectionné, une solution, puis trois projets de cette solution ainsi que les classes qui nous interessent pour avoir une vision de l'architecture :


(Cliquer pour agrandir)

Une vue intéressante est la vue matricielle par dépendances qui permet de montrer la dépendance entre les différents objets selectionnés et donc ainsi d'évaluer visuellement les impacts potentiels induits par des demandes de changement :


(Cliquer pour agrandir)

Cet outil constitue desormais le point d'entrée incontournable de l'architecte souhaitant analyser ou accèder à des éléments d'un projet de développement.
Cet outil s'inscrit clairement dans la démarche de Microsoft pour la gestion de la complexité à l'aide d'outils visuels et intelligents.

UML comme langage de modélisation logique dans ROSARIO
Un nouveau type de projet fait son apparition dans Visual Studio : Les projets de modélisation.

On dénombre non moins de 5 types projets de modélisation UML disponibles :

  • Les diagrammes d'activité
  • Les diagrammes de composants
  • Les diagrammes logique de classe
  • Les diagrammes de cas d'utilisation
  • Les diagrammes de séquence
La qualité des diagrammes produits ne laissera sans doute pas indifférent des utilisateurs d'outils de modélisation professionels tel que Sparx Enterprise Architect.

Nous allons regarder comment mettre en oeuvre ces différents types de diagrammes en utilisant la dernière version de Visual Studio.

Les diagrammes de cas d'utilisation (Use Case)
Rappel : Ces diagrammes permettent d'identifier les possibilités d'interaction entre un système et ses acteurs (intervenants extérieurs au système), c'est-à-dire toutes les fonctionnalités que doit fournir le système.
Ci dessous la barre d'outils permettant de concevoir un cas d'utilisation dans la nouvelle version de Visual Studio.

La création d'un cas d'utilisation est extrêmement simple dans Rosario et permet notamment de relier le Use Case à un Work Item.
On remarquera également une touche intéressante permettant de connecter à tout Use Case un objet Use Case details permettant de spécifier les pré et post conditions , les principales étapes du Workflow ainsi que des information sur la gestion d'exceptions attendues. Ci dessous, un exemple de Use Case réalisé avec la CTP d'Avril


(Cliquer pour agrandir)

Les diagrammes de composants
Rappel : Ces diagrammes permettent de montrer les composants du système d'un point de vue physique, tels qu'ils sont mis en œuvre (assemblies, fichiers, bases de données etc.)
la boite à outils permettant la conception de ce diagramme se présente tel qu'illustré ci dessous :

Quelques minutes suffisent également pour construire ce diagramme :

Les diagrammes de classes
Rappel : Ces diagrammes affichent les classes présentes dans le système et affichent les opérations et attributs de la classe.
La Boite à outil dispose de la totalité des éléments pour la construction de diagrammes de classes conformes à la version 2.1 d'UML :

Les DiagrammeS de classes logiques peuvent être crées from scratch ou obtenus par simple processus de retro-conception à partir de classes existantes dans un projet. Ces diagrammes peuvent être utilisés pour interopérer avec des diagrammes de séquences ou encore faire évoluer les classes existantes.



Les diagrammes de séquence

Rappel : Ces diagrammes permettent une représentation séquentielle du déroulement des traitements et des interactions entre les éléments du système et/ou de ses acteurs.
Avec le module UML de Team Architect Rosario, on peut :
  • Soit à partir d'un diagramme de séquence existant ou crée, générer le code associé donc les opérations sur des classes ou encore les classes elles mêmes.
  • Soit à partir de code existant grace à un mécanisme de retro conception générer le diagramme de séquence associé.
Pour illustrer cette nouvelle fonctionnalité, nous allons créer un petit exemple.
Dans l'exemple ci dessous, on crée simplement un petite application Winform dont le but est d'afficher le nom d'un client dans une TextBox par un simple clic sur un bouton GetCustomer.
Dans le processus implémenté, une classe getcustomer est instanciée, le nom du client récupéré puis une opération de validation et finalement d'affichage est lancée. par le code du bouton. Nous allons générer le diagramme de séquence de cette action en quelques secondes grâce au nouveau module Team Architect.
Etape 1, on ajoute un diagramme de séquence à notre projet Customer : Add / New Item / General / Sequence Diagram

Le Diagramme est ajouté au projet

Pour l'étape suivante, il faut s'assurer que le diagramme de séquence soit ouvert (actif). ouvrir l'architecture Explorer ( View / Architecture Explorer), puis naviguer dans la solution, le projet etc. jusqu'à atteindre l'evènement on_click du bouton pour voir apparaitre dans la dernière fenetre la commande "Insert into Active Diagram" comme indiqué dans la figure ci dessous.


(Cliquer pour agrandir)

Le cheminement exact est :

  • Column 1) "NomDeLaSolution" Solution
  • Column 2) Contains
  • Column 3) "Customer" Project
  • Column 4) Contains
  • Column 5) "CustomerForm" Formulaire
  • Column 6) Contains
  • Column 7) "GetCustomer_Click" Evènement du bouton
  • Column 8) Insert into Active Diagram Commande de génération du diagramme
Après avoir cliquer sur ce dernier lien, une jauge apparait dans la fenêtre indiquant la complétion du processus de création du diagramme de séquence. Pour terminer activer la fenêtre du diagramme pour visualiser le résultat :


(Cliquer pour agrandir)

On notera ici la puissance de cette outil pour découvrir l'ordonnancement des processus et des appels ainsi que les objets concernés dans une solution existante.
On pourra enfin si on le souhaite modifier le modèle existant simplement en modifiant le diagramme puis générer les nouvelles classes ou méthodes tel qu'illustré ci dessous :

Les diagrammes d'activité
Rappel : Ce diagramme permet de décrire sous forme de flux ou d'enchaînement d'activités le comportement du système ou de ses composants.
Tel qu'illustré ci dessous, à l'aide d'une barre d'outils riche, il est simple et rapide de réaliser de tels diagrammes :

Les diagrammes sont réalisés en quelques minutes :

Le support d'UML 1.2 dans Rosario constitue une avancée énorme, qui permettra de travailler plus en amont avec l'outil lors des phases de modélisation et d'analyse, de documenter les taches affectées aux développeurs simplement en reliant ces diagrammes aux Work items, l'outil pourra permettre aux Business Analystes de travailler connecté à Rosario et produire des artefacts de modélisation venant complèter le systeème d'information projet géré par TFS. Les Architectes trouveront dans ce nouvel outil, l'opportunité d'une part de réaliser leur diagrammes directement dans Rosario donc ne plus multiplier les outils tiers, relier leurs diagrammes aux Work Packages du WBS projet. De plus, les diagrammes de séquences pourront être d'un aide précieuse lors de mission d'audit pour mieux comprendre le comportement dynamique d'une application.
Les puristes regretteront qu'un client spécifique n'ait pas été fourni comme cela a été le cas pour la partie Testing avec Camano, de manière à pouvoir mettre facilement ce produit à disposition de Business Analystes et éviter d'installer Visual Studio.

Intégration de Software Factories via les DSL

Dans la future version Rosario Team Architect, de nouvelles fonctionnalités vont apporter une productivité netttement améliorée tant au niveau du Design que du développement d'architectures. Ces nouvelles fonctionnalités sont de deux ordres :

  • l'intégration de Software Factories issues d'une étroite collaboration des équipes de ROSARIO et des équipes de Patterns & Practices (WSSF,WCSF...)
  • l'intégration de nouveaux designers basés sur la technologie DSL.

Les modèles de factories, s'appuyant sur GAT et GAX, et pourront être téléchargées pour venir enrichir les modèles proposés en standard, on retrouve donc dans ce module Team Architect cette capacité à étendre er personnaliser les outils. Ce module va permettre en plus des DSL existante d'aller jusqu'à la conception graphique de services WCF à partir des diagrammes DSL de type Application Designer, et bien évidemment générer le code à partir des paramètres entrés. Cette fonctionnalité ne faisant pas partie de la CTP d'avril, il n'est pas possible de procéder à une mise en oeuvre concrète de ce produit.