Objet

  • Fournir 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égler un ou plusieurs défauts. 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".
Rôle :  Implémenteur 
Fréquence :   Lors de chaque itération (à l'exception éventuellement des itérations de création, lorsqu'aucun prototype n'est requis) 
Etapes
Artefacts d'entrée :    Artefacts de sortie :   
Guides d'utilisation de l'outil :   
Plus d'informations : 

Détails de l'enchaînement d'activités :   

Préparer l'implémentation Haut de la page

Compréhension de la tâche/du problème

Avant de commencer une activité 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 activité 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. Cela doit s'appliquer aux éléments à mettre à jour et aux différents éléments nécessaires à la compilation et aux tests d'unités. L'implémenteur doit connaître et suivre la configuration du projet et les procédures de gestion des changements. Ces procédures 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, regardez s'il est possible de réutiliser ou d'adapter du code existant. La compréhension de la manière dont l'implémentation s'intègre dans l'architecture et la conception du reste du système peut aider l'implémenteur à identifier les opportunités de réutilisation. Cela permettra également d'assurer l'adéquation de l'implémentation au reste du système.

Implémentation incrémentielle

Nous vous recommandons de réaliser une implémentation incrémentielle en compilant, en associant et en exécutant des tests de régression plusieurs 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 anomalies, 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. Vous devez réaliser les modifications une par une, car la correction d'erreurs peut engendrer elle-même des erreurs. L'implémentation des corrections doit se faire de manière incrémentielle afin de localiser facilement l'origine d'éventuelles erreurs nouvelles.

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

Transformer la conception en implémentation Haut de la page

Il existe diverses techniques de transformation de la conception en implémentation. Exemples :

  • Des modèles visuels spécifiques aux plates-formes peuvent être utilisés pour générer un canevas initial de code. Ce canevas de code peut ensuite être affiné avec du code supplémentaire qui n'est pas mentionné 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, prenez la conception et ajoutez les détails d'implémentation directement au modèle.
  • La conception peut être indépendante de la plate-forme à différents degrés ; les modèles de conception ou le code spécifiques à la plate-forme peuvent être générés par des transformations utilisant diverses règles permettant de décider la manière dont les abstractions globales doivent être mappées aux éléments spécifiques à la plate-forme. 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.

Terminer l'implémentation Haut de la page

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 terminer l'implémentation. Par exemple :

  • Adapter 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 :
    • compléter les opérations décrites dans la conception
    • ajouter les classes, opérations et structures de données de support

Evaluer l'implémentation Haut de la  page

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

  • Lire le code. Penser à conserver une liste de contrôle des erreurs les plus courantes que vous avez commettez dans les implémentations.
  • 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.

Fournir un retour d'informations à l'équipe de conception Haut de la page

Au fur et à mesure de l'implémentation et du test des conceptions, des erreurs affectant 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.



RUP (Rational Unified Process)   2003.06.15