Concepts :
|
Activités au cours du cycle de vie : |
Rubriques supplémentaires:
|
Le développement basé sur les composants est une variante du développement d'applications général dans lequel :
- L'application est assemblée à partir de composants non intégrés exécutables qui sont développés et déployés de façon relativement indépendante les uns des autres, si possible par différentes équipes.
- L'application peut être mise à jour en incréments plus petits en mettant uniquement à jour certains des composants qui forment l'application.
- Les composants peuvent être partagés entre les applications, ce qui crée des opportunités de réutilisation, mais également des dépendances inter-projet.
- les applications basées sur des composants sont généralement de type réparties bien que cela n'ait pas de relation directe avec le fait qu'elles soient basées sur des composants.
Sur cette page, le terme "composant" est utilisé pour faire référence aux composants déployables et développés de façon indépendante. Toutefois, ailleurs dans RUP, nous utiliserons le terme "composant" dans son acceptation plus générale décrite dans Concepts : Composant, en le précisant si nécessaire.
L'adaptation du Rational Unified Process (RUP) aux défis du développement basé sur les composants est abordée ci-après.
L'enchaînement des activités de base pour la phase de création s'applique, avec les extensions ou les variantes suivantes :
Le centre d'intérêt de Activité : Développer une étude de rentabilité est adapté afin de prendre en compte le fait que l'utilisation de composants modifie la structure de coût du développement. Plus particulièrement, le coût de développement des composants diminue mais on passe plus de temps à identifier les composants et à vérifier que les composants sélectionnés correspondent aux exigences.
Une approche axée sur les composants modifie la nature de certains risques et introduit de nouveaux risques. En particulier :
Dans l'Activité : Planifier les phases et les itérations, le plan de la phase de construction peut éventuellement afficher le fractionnement du projet en deux pistes différentes mais parallèles : une qui développe les composants propres au domaine et à l'application (situé dans les couches supérieures de l'architecture - voir Concepts : Organisation en couche), et une pour les composants qui ne sont pas propres au domaine et à l'application situés dans les couches inférieures. Dans certains cas, des composants réutilisables seront développés par les équipes de développement gérées de façon indépendante. La décision d'introduire des pistes parallèles est essentiellement une question de ressource et de dotation en personnel née de la volonté de gérer des composants réutilisables comme des ressources indépendantes des applications dans lesquelles les composants sont déployés.
Au moment de la précision des exigences du système, les contraintes imposées par l'infrastructure de composants sélectionnée doivent être consignées. Les infrastructures des composants améliorent la productivité du développement notamment en limitant le degré de liberté proposé par l'architecte logiciel et le concepteur. L' Activité : Détailler les exigences logicielles doit s'attacher à documenter ces contraintes.
Il faut créer un plan de tests identifiant l'ensemble des tests que l'on veut effectuer dans le cadre du projet, appelé "plan de tests principal".
Lorsque vous recueillez et préparez les recommandations pour le projet, prenez en compte l'infrastructure spécifique des composants et les contraintes qu'elle impose. Les recommandations doivent indiquer la façon de concevoir et de codifier en utilisant l'infrastructure. Elles doivent également donner une orientation sur la manière de vérifier la conformité avec l'infrastructure de composants elle-même et et les interfaces définies entre les composants.
Pour la phase d'élaboration l'enchaînement des activités de base s'applique, avec les extensions et les variantes suivantes :
L'Activité: Détailler les exigences du logiciel se concentre davantage sur les exigences techniques et non fonctionnelles et sur les contraintes imposées par les composants qui sont soit construits soit achetés. Les exigences spécifiques non-fonctionnelles à prendre en compte sont la taille, la performance, l'encombrement du disque ou de la mémoire, les questions relatives à la licence d'exécution, et les contraintes analogues qui auront une influence sur la sélection ou la construction des composants.
L' Activité : Analyse architecturale utilise l'infrastructure de composants et les exigences techniques et non-fonctionnelles afin de définir une architecture initiale, comprenant un schéma d'organisation en couche et un ensemble par défaut de composants et de services (représentés comme des mécanismes d'analyse et de conception). L' Activité : Analyse des cas d'utilisation se concentre sur l'identification des composants significatifs du point de vue architectural à partir des cas d'utilisation significatifs du point de vue architectural.
L'Activité : Structurer le modèle d'implémentation établit un modèle d'implémentation compatible avec l'infrastructure des composants et la structure et les responsabilités de/des l'équipe(s) de développement.
L' Activité : Identifier les mécanismes de conception permettra d'affiner les mécanismes de conception initiaux pour prendre en compte les composants et services de l'infrastructure.
L'Activité : Identifier les éléments de conception permettra d'identifier les principaux composants du système significatifs du point de vue architectural. Les responsabilités potentiellement réutilisables doivent être regroupées pour une meilleure réutilisabilité ; la fonctionnalité propre à l'application doit être séparée de la fonctionnalité propre au domaine et de la fonctionnalité indépendante au domaine et à l'application. Dans le cadre de la conception, les composants peuvent être représentés comme un Artefact : Concevoir un sous-systèmes. Artefact: Interfaces doit être identifié pour ces composants/sous-systèmes.
L' Activité : Incorporer des éléments de conception existants s'assurera que les composants identifiés sont cohérents et compatibles aux composants existants identifiés lors des itérations précédentes, dans l'infrastructure elle-même, ou à partir de sources extérieures.
L' Activité : Description de l'architecture d'exécution permet de décrire l'architecture du processus de base de l'infrastructure de composants, alors que l' Activité : Décrire la répartition décrit l'environnement informatique réparti dans lequel l'application des composants s'exécutera.
L' Activité : Conception des sous-systèmes affine davantage la conception des composants, en identifiant des classes dans le composant qui fournissent le véritable comportement du composant. Au début de la phase d'élaboration, il n'y aura probablement qu'une seule classe, une sorte de "proxy sous-système/composant" qui agit comme un raccord pour stimuler le comportement du composant afin de prototyper l'architecture. Plus tard, le comportement de cette classe est réparti dans une collaboration de classes contenues dans le sous-système. Ces classes sont affinées dans l' Activité : Concevoir les classes.
L'objectif de l'élaboration est de garantir que la stratégie de persistance est évolutive et que la conception de la base de données et le mécanisme de persistance prendra en charge les besoins en débit du système. Les classes persistantes sont identifiées et mappées au mécanisme de persistance. Les cas d'utilisation faisant un usage intensif des données sont analysés pour s'assurer que les mécanismes seront évolutifs. En conjonction avec les détails de l'enchaînement des activités de test, le mécanisme de persistance et la conception de la base de données sont évalués et validés.
L' Activité : Implémentation des éléments de conception doit se conformer aux contraintes imposées par l'infrastructure de composants. Dans la phase d'élaboration, la plupart des composants contiendront un grand nombre de codes de "raccords" puisque ici l'implémentation se concentre sur la validation de l'architecture et non pas sur la production de code d'une qualité adaptée à la production.
Les activités de test dans l'élaboration consistent à valider l'architecture. Pour un système basé sur les composants, cet objectif conduit à :
Toutes les hypothèses inhérentes dans l'infrastructure de composants doivent être également évaluées. Celles-ci incluent en général la capacité d'évolution et le débit des mécanismes de persistance et de gestion des transactions dans lesquels des hypothèses cachées faites par le concepteur des mécanismes amoindrissent souvent en réalité l'architecture de l'application si elle ne comprend pas l'hypothèse.
En utilisant les sous-systèmes d'implémentation comme des "unités logiques de responsabilité", le travail de construction peut être divisé en deux "pistes" parallèles ou plus : une qui se concentre sur la fonctionnalité propre à l'application, et une ou plusieurs qui se concentrent sur des composants génériques réutilisables. Cela dépend bien sûr des ressources que l'on aura en personnel et si elles sont suffisantes pour des efforts de développement parallèles. La capacité à diviser les équipes de développement et à travailler en parallèle dépend totalement 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 au niveau de la phase d'élaboration permettra cette division.
Pour la phase de construction l'enchaînement des activités de base s'applique, avec les extensions et les variantes suivantes :
La planification de la première itération de construction a été décrite précédemment, car elle se produit vers la fin de l'élaboration. Le planning du suivi de l'itération et la capacité à diviser les équipes de développement et à travailler en parallèle continuent à dépendre de la stabilité de l'architecture et de la qualité et de la stabilité des interfaces entre les composants.
L'objectif dans la construction est d'analyser le reste des cas d'utilisation et d'identifier les composants appropriés et les collaborations de composants qui réalisent les cas d'utilisation. L'architecture existante est développée et complétée et les "comportements internes" des composants sont totalement conçus et implémentés.
La phase de construction s'axe sur l'achèvement de la conception de la base de données, en s'assurant que toutes les classes persistantes sont prises en charge à la fois par la base de données et par le mécanisme de persistance. Ce travail est effectué en parallèle et de façon itérative avec le travail exécuté dans Détails de l'enchaînement des activités : Affiner l'architecture et Détails de l'enchaînement des activités : Concevoir les composants. L'organisation idéale est d'avoir des équipes de composants intégrées, avec une coordination croisée entre les équipes sur les questions de persistance afin de garantir un bonne conception de la base de données.
Ici le travail est similaire à celui effectué au niveau de l'élaboration mais les informations restantes sont de plus en plus complètes au fur et à mesure que la phase progresse.
Le système est construit progressivement au fur et à mesure que la phase se poursuit.
Les tests de performance restent importants, mais on porte de plus en plus d'attention aux tests fonctionnels. L'intégralité de la fonctionnalité, les tests de régression de la fonctionnalité existante ainsi que la conformité avec les attentes en matière de performance doivent être satisfaits.
RUP (Rational Unified Process)
|