Tâche: Implémenter les éléments de conception
Cette tâche explique comment produire une implémentation pour une partie de la conception (comme par exemple une classe, une réalisation de cas d'utilisation ou une entité de base de données) ou pour résoudre un ou plusieurs incidents. Le résultat conduit habituellement à l'obtention d'un code source et de fichiers de données nouveaux ou modifiés, appelés "Eléments d'implémentation".
Disciplines: Implémentation
Relations
Etapes
Préparation de l'implémentation
Compréhension de la tâche/du problème

Avant de commencer une tâche d'implémentation, l'implémenteur doit clarifier sa portée, conformément aux spécifications des affectations de tâches et des plans d'itération. Une tâche d'implémentation peut avoir pour but d'accomplir une fonction spécifique (comme par exemple l'implémentation d'une réalisation de cas d'utilisation ou la correction d'une anomalie) qui implique l'implémentation de plusieurs éléments de conception contribuant à cette fonction. Sinon, une tâche d'implémentation peut être concentrée sur un élément de conception particulier, comme par exemple un sous-système de conception ou un classe de conception, en l'implémentant dans la limite fixée pour l'itération courante.

Configuration de l'environnement de développement

Cette tâche aboutit à la création ou à la mise à jour d'un ou de plusieurs fichiers (éléments d'implémentation). Dans le cadre de la préparation de l'implémentation, l'implémenteur doit s'assurer que son environnement de développement est correctement configuré, de sorte que les versions d'éléments appropriées soient disponibles (aussi bien les éléments à mettre à jour que tout autre élément nécessaire à la compilation et au test d'unité). L'implémenteur doit connaître et suivre les procédures de gestion de la configuration et des changements du projet, qui décrivent la manière de contrôler et d'éditer les changements et de les distribuer pour intégration.

Analyser l'implémentation existante

Avant d'implémenter une classe en partant de zéro, regardez s'il est possible de réutiliser ou d'adapter du code existant. En comprenant où l'implémentation s'intègre dans l'architecture et la conception du reste du système, et en vérifiant qu'elle s'intègre dans le reste du système, l'implémenteur identifie plus facilement de telles possibilités de réutilisation.

Implémentation incrémentielle

Nous vous recommandons de réaliser une implémentation incrémentielle : compilez, associez et exécutez des tests de régression deux fois par jour. Il est important de savoir que l'ensemble des opérations, des attributs et des associations publics ne sont pas définis pendant la conception.

Lorsque vous gérez des incidents, vérifiez que vous avez bien corrigé le problème et non le symptôme ; vous devez vous attacher à corriger le problème sous-jacent dans le code. Effectuez un seul changement à la fois. La correction d'erreurs étant elle-même source de fautes, il est important d'implémenter les corrections de manière incrémentielle, afin de localiser plus facilement la provenance de nouvelles erreurs.

L'implémenteur doit connaître et suivre toutes les instructions d'implémentation spécifiques au projet, y compris les recommandations de programmation applicables aux langages de programmation spécifiques.

Transformation de la conception en implémentation

Il existe diverses techniques de transformation de la conception en implémentation. En voici quelques exemples :

  • Des modèles visuels spécifiques aux plates-formes peuvent être utilisés pour générer un canevas initial de code. Cette infrastructure de code peut ensuite être affinée avec du code supplémentaire qui n'est pas spécifié dans la conception.
  • Les modèles peuvent être détaillés et utilisés pour générer des prototypes exécutables. Les diagrammes de structure (diagrammes de classes et de packages) et de comportement (comme les diagrammes d'état et d'activité) peuvent tous deux être utilisés pour générer du code exécutable. Ces prototypes pourront être affinés ultérieurement selon les besoins.
  • Les modèles peuvent aussi être détaillés jusqu'au point où le modèle représente complètement l'implémentation. Dans ce cas, plutôt que de transformer une conception abstraite en une implémentation de code, il suffit d'ajouter les détails d'implémentation directement au modèle dans la conception.
  • La conception peut être indépendante de la plateforme selon différents degrés. Les modèles de conception spécifiques à la plateforme, voire le code, peuvent être générés au moyen de transformations qui appliquent différentes règles pour mapper les éléments propres à la plateforme dont les abstractions sont de haut niveau. Cette notion est la clé de voûte de l'architecture MDA (Model Driven Architecture) de l'Object Management Group (OMG) (http://www.omg.org).
  • Des patterns standard peuvent également être appliqués, pour générer les éléments de conception et de code à partir de la conception et de l'implémentation qui leur sont associées. Par exemple, un pattern standard de transformation peut être appliqué à une table des données, pour créer des classes java permettant d'accéder à la table de données. Un autre exemple consiste à utiliser une infrastructure de modélisation Eclipse (http://www.eclipse.org/emf/) pour générer du code de stockage des données correspondant au modèle et pour générer une implémentation d'interface utilisateur pour remplir les données.

Dans tous les cas, cependant, certaines abstractions de conception sont détaillées pour devenir l'implémentation, soit en mode manuel soit par l'intermédiaire de l'application de certaines transformations automatisées.

Achèvement de l'implémentation

Comme cela est décrit dans l'étape précédente, la transformation de la conception en implémentation peut aboutir à différents niveaux de finalisation de l'implémentation. Cela peut être une implémentation complète et acceptable. Habituellement, un effort substantiel est néanmoins nécessaire pour achever l'implémentation. Il faut par exemple :

  • Optimiser les résultats de la transformation (par exemple, pour améliorer les performances ou améliorer l'interface utilisateur)
  • Ajouter les détails manquants, comme :
    • terminer les opérations décrites dans la conception (choisir des algorithmes et écrire le code)
    • ajouter des classes, opérations et structures de données de support
Evaluation de l'implémentation

Il s'agit de vérifier si l'implémentation remplit son objectif.  En plus des tests (décrits dans les autres tâches), il est souvent utile de réaliser certaines vérifications supplémentaires :

  • Parcourez manuellement le code. Pensez à conserver une liste de contrôle des erreurs les plus courantes que vous commettez dans vos implémentations, et recherchez-les.
  • Utiliser des outils pour vérifier si le code contient des erreurs. Par exemple, un vérificateur de règle de code statique ou un compilateur avec niveau d'alerte.
  • Utiliser des outils permettant de visualiser le code. La visualisation du code peut aider l'implémenteur à identifier des problèmes spécifiques comme un couplage excessif, des dépendances circulaires et ainsi de suite.
Retour d'informations à l'équipe de conception

Au fur et à mesure de l'implémentation et du test des conceptions, des erreurs, affectant souvent la conception, sont inévitablement découvertes. Si l'abstraction de conception est maintenue dans le cadre d'une maintenance future ou pour des raisons contractuelles ou liées à la communication, alors cette conception doit être mise à jour.

Pour cela, la méthode utilisée dépend du processus de gestion de la configuration et des changements applicable au projet. En règle générale, si la modification requise est peu importante, et si la même personne est chargée de la conception et de l'implémentation de la classe, il n'est pas nécessaire d'élaborer une demande de changement formelle. Cette personne peut apporter la modification requise dans la conception.

Si la modification requise a une forte répercussion, comme par exemple la modification d'une opération publique, alors il pourrait s'avérer nécessaire de soumettre une demande de changement formelle.



Plus d'informations