Concept: Développer des solutions de composant
Le développement basé sur les composants est une variante du développement général d'application. Dans ces instructions, "composant" fait référence aux composants déployables et développés séparément.
Description principale
Activités à travers le cycle de vie :
  1. Introduction
  2. Phase de création
  3. Phase d'élaboration
  4. Phase de construction
  5. Phase de transition
Rubriques supplémentaires :

Introduction

Le développement à base de composants est une variante du développement général d'application dans lequel :

  • L'application est créée à partir de composants exécutables discrets qui sont développés et déployés de manière relativement indépendante, potentiellement par des équipes différentes.
  • L'application peut être mise à niveau en incréments plus petits en mettant uniquement à jour certains des composants qui forment l'application.
  • Les composants peuvent être partagés par plusieurs applications ce qui permet une réutilisation mais crée aussi des dépendances inter-projets.
  • Bien que cela ne soit pas directement lié au fait d'être basées sur les composants, les applications basées sur les composants sont généralement réparties.

"Composant" fait référence dans cette page aux composants déployables et développés séparément. Partout ailleurs dans RUP, nous utiliserons le terme "composant" au sens plus général décrit dans Concept : composant et ferons la nuance si nécessaire.

L'adaptation de Rational Unified Process (RUP) aux défis du développement basé sur les composants fait l'objet de la discussion ci-dessous.

Phase de création

L'enchaînement d'activités pour la Phase de création s'applique avec les extensions ou les variations suivantes :

Gestion de projet

  • Activité : Evaluer la portée et les risques du projet
  • En ayant recours à une approche relative aux composants, la nature de certains risques est modifiée et de nouveaux risques apparaissent. En particulier :

    • Les composants externes accentuent les risques car ils introduisent des éléments critiques qui ne sont pas sous le contrôle direct de l'équipe du projet
    • Les composants externes peuvent réduire la durée du développement, réduisant ainsi le risque de ressource
    • Les composants externes peuvent altérer l'architecture du système s'ils imposent leurs propres restrictions architecturales
  • Activité : Planification du projet
  • Dans la Tâche : Planifier les phases et les itérations, la planification de la phase de construction peut éventuellement montrer le projet se divisant en deux chemins différents mais parallèles : un qui développe les composants spécifiques à l'application et au domaine (organisés dans les couches supérieures de l'architecture - voir Concept : Organisation en couches) et les composants non spécifiques à l'application et au domaine organisés dans les couches inférieures. Dans certains cas, les composants réutilisables seront développés par des équipes de développement gérées séparément. La décision d'introduire des chemins parallèles est une question de personnel et de ressources introduite par un désir de gérer des composants réutilisables en tant qu'actifs indépendants des applications dans lesquelles ils sont déployés.

Recueil des exigences

  • Activité : détail de la définition du système
  • Lors du détail des exigences du système, les contraintes imposées par l'infrastructure préfabriquée du composant sélectionné doivent être capturées. Les infrastructures prédéfinies du composant améliorent la productivité de développement en partie en limitant les degrés de liberté dont dispose le concepteur et l'architecte du logiciel. La Tâche : Détailler les exigences logicielles doit porter essentiellement sur ces contraintes.

Test

Environnement

  • Activité : Préparation de l'environnement pour le projet
  • Lors de la collecte et la préparation des instructions relatives au projet, voir Tâche : Préparation des instructions relatives au projet pour une documentation détaillée,  et prendre en compte l'infrastructure préfabriquée spécifique du composant et les contraintes qu'il impose. Les instructions doivent décrire comment concevoir et coder à l'aide de l'infrastructure préfabriquée. Elles doivent aussi fournir des indications relatives au test pour savoir comment vérifier la conformité à la fois avec l'infrastructure préfabriquée elle-même et les interfaces définies entre les composants.

Activités de la phase d'élaboration

L'enchaînement d'activités de base s'applique pour la phase d'élaboration avec les extensions ou les variations suivantes :

Recueil des exigences

  • Activité : détail de la définition du système
  • La Tâche : Détailler les exigences logicielles met aussi l'accent sur les exigences techniques et non fonctionnelles et les contraintes imposées aux composants qui sont soit construits soit achetés. les exigences non fonctionnelles spécifiques à prendre en compte sont la taille, la performance, l'encombrement de la mémoire ou du disque dur, les questions de licence d'exécution et les contraintes similaires qui influenceront la sélection ou la construction du composant.

Analyse & conception

  • Activité : Conception de composants
  • La Tâche : conception de sous-système détaille davantage la conception des composants en identifiant les classes au sein des composants qui donnent le comportement réel du composant. Dans les premières étapes de la phase d'élaboration, il se peut qu'il y ait une classe unique, une sorte de "sous-système/composant proxy" qui agit comme un raccord afin de stimuler le comportement du composant à des fins d'élaboration de prototype architectural. Le comportement de cette classe est distribué plus tard à une collaboration de classes contenues dans le système. Ces classes sont détaillées dans la Tâche : Conception de classe.

  • Activité : Conception de la base de données
  • L'élaboration a pour objet principal de s'assurer que la stratégie de persistance est évolutive et que la conception de la base de données et le mécanisme de persistance supportent les exigences de débit du système. Les classes persistantes sont identifiées et mappées au mécanisme de persistance. Les cas d'utilisation avec beaucoup de données sont analysés pour s'assurer que les les mécanismes seront évolutifs. En conjonction avec les activités de test, le mécanisme de persistance et la conception d'une base de données sont évalués et validés.

Implémentation

Test

  • Activités : Définir la mission d'évaluation, Vérifier l'approche de test, Tester et évaluer, Accomplir une mission acceptable, Améliorer les actifs de test

    Les activités de test dans la phase d'élaboration portent sur la validation de l'architecture. Pour un système basé sur les composants, cet accent devient :

    • appliquer les interfaces entre les composants pour s'assurer que les frontières de composants sont appropriées
    • un accent plus fort mis sur le test de performance, en particulier les tests d'échelonnement de la performance pour s'assurer que les volumes de transaction anticipés peuvent être soutenus

    Toute hypothèse qui s'y rattache dans l'infrastructure préfabriquée du composant doit aussi être évaluée. Elles portent en général sur la mise à l'échelle et le rendement de la persistance et les mécanismes de gestion de la transaction dans lesquels les hypothèses inavouées du concepteur du mécanisme affaiblissent souvent l'architecture de l'application de manière effective si elle ne comprend pas l'hypothèse.

Gestion de projet

  • Activité : Planification de l'itération suivante

    En utilisant les sous-systèmes d'implémentation en tant qu'"unités logiques de responsabilité", le travail de construction peut être divisé en deux ou plusieurs "chemins" parallèles : l'un qui porte sur la fonctionnalité propre à l'application et l'autre ou les autres sur des composants génériques réutilisables. Cela dépend bien sûr si le nombre de ressources est suffisant aux efforts parallèles de développement du personnel. La capacité à diviser les équipes de développement et à travailler en parallèle dépend largement de la stabilité de l'architecture et plus particulièrement de la qualité et de la stabilité des interfaces entre les composants. Un effort important fourni dans la phase d'élaboration permet cette division.

Activités de la phase de construction

L'enchaînement d'activités de base s'applique pour la Phase de construction avec les extensions et les variantes suivantes :

Gestion de projet

  • Activité : Planification de l'itération suivante

    La planification de la première itération de la construction a été décrite précédemment puisque cette dernière a lieu vers la fin de l'élaboration. La planification des itérations qui suivent et la capacité à diviser les équipes de développement et travailler en parallèle dépend toujours de la stabilité de l'architecture et de la qualité et de la stabilité des interfaces entre les composants.

Analyse & conception

  • Activité : Détail de l'architecture et Activité : Composants de conception

    La construction a pour objet principal l'analyse du reste des cas d'utilisation et l'identification des composants appropriés et des collaborations du composant qui réalisent les cas d'utilisation. L'architecture existante est élargie et complétée et les "comportements internes" du composant sont entièrement conçus et implémentés.

  • Activité : Conception de la base de données

    La construction a pour objet principal de terminer la conception de la base de données, en s'assurant que que toutes les classes persistantes sont supportées par la base de données et le mécanisme de persistance. Ce travail est effectué en parallèle et de façon itérative avec le travail effectué dans l'Activité : Détail de l'architecture et Activité : Composants de conception. Une organisation idéale est d'avoir intégré les équipes du composant, avec une coordination entre les équipe sur les questions de la persistance afin d'assurer une bonne conception de la base de données.

Implémentation

Test

Tester la performance reste vital mais l'accent est de plus en plus mis sur le test fonctionnel. L'achèvement de la fonctionnalité, le test de régression de fonctionnalité existante ainsi que la conformité aux attentes de performance doivent être traités.

Activités de la phase de transition

  • L'édition du produit dans l'environnement Web tend à être incrémentielle, continue et moins focalisée sur la distribution traditionnelle des supports. La planification de l'édition doit être ajustée en conséquence.
  • Cette phase se focalise de plus en plus sur le support de la production.
  • Les activités de conversion de données sont effectuées.