Conception de logiciels et développement avec Rational Software Architect

Les systèmes peuvent être construits de manière plus efficace et déployés avec les meilleures chances de succès lorsque la spécification architecturale est claire et que toutes les parties prenantes se mettent d'accord sur la conception très tôt dans le cycle de vie du projet.

Développement itératif

Le processus RUP (Rational Unified Process) préconise que la conception et le développement du logiciel se déroulent en quatre phases : la création, l'élaboration, la construction et la transition. Le processus met l'accent sur l'adoption de pratiques de développement d'application permettant de s'assurer que l'équipe de développement effectue les activités importantes suivantes, à l'intérieur et entre ces phases.
  • Gestion des exigences
  • Modélisation visuelle, à l'aide du langage UML (Unified Modeling Language)
  • Développement itératif
  • Contrôle des modifications
  • Contrôle continu de la qualité
Pour se conformer aux principes du processus RUP et appliquer les pratiques éprouvées de gestion du cycle de développement de logiciel, votre équipe peut utiliser Rational Software Architect.
  • Collecte des exigences et modélisation du cas d'utilisation

    Les exigences peuvent provenir de différentes sources, que les analystes et les architectes du système doivent fusionner dans une documentation d'exigences avant de les gérer. A partir de ces exigences, votre équipe peut établir des cas d'utilisation du système et un comportement du système de niveau supérieur.

    Les équipent qui utilisent Rational RequisitePro peuvent recourir à la perspective de gestion des exigences établir le lien entre les définitions d'exigences existantes et les éléments de modèle UML existants (les cas d'utilisation, par exemple). Vous pouvez également créer des exigences à partir d'éléments de modèle existants ou créer des éléments de modèle à partir de définitions d'exigences existantes.

    L'architecte logiciel crée un modèle de cas d'utilisation afin de définir les cas d'utilisation, le comportement et les acteurs du système, ainsi que pour spécifier les flux de travaux (workflows) de l'utilisateur.

  • Analyse du domaine

    Les analystes et les architectes décrivent le domaine du système en définissant un modèle fonctionnel de haut niveau. La phase d'analyse permet d'identifier les données qui vont être stockées dans le système et la manière dont elles vont être traitées.

    L'architecte crée un modèle d'analyse afin d'établir une vue logique des exigences fonctionnelles. Ce modèle permet de définir les objets de niveau supérieur du système et de définir leurs interactions.

  • Conception architecturale détaillée

    L'architecte, avec la collaboration de l'équipe de développement d'application, conçoit l'architecture du système de façon détaillée.

    Lors de la conception détaillée, l'équipe de développement utilise le modèle de niveau supérieur créé lors de l'analyse pour créer un modèle de conception. Les développeurs ajoutent des caractéristiques au modèle afin de décrire l'implémentation du système (les éléments et technologies de programmation utilisés pour la persistance, la sécurité, la journalisation et le déploiement, par exemple).

    Le modèle de conception peut être affiné en appliquant des patterns de conception éprouvés et des transformations modèle vers modèle automatisées.

  • Implémentation

    L'équipe de développement utilise la conception approuvée pour implémenter l'application.

    Les développeurs passent de la conception à l'implémentation grâce à des transformations automatisées qui permettent de convertir le modèle en code (Java, EJB (Enterprise JavaBeans), C++ ou IDL CORBA, par exemple) et en poursuivant le développement et le déploiement de l'application à l'aide des capacités de développement Web, de débogage, de test et de déploiement.

    Les développeurs d'applications Java peuvent tirer profit des fonctions additionnelles d'analyse structurelle et de contrôle afin de vérifier que leur code est conforme aux règles structurelles prédéfinies et à d'autres règles personnalisées. Ils peuvent en outre rechercher les patterns structurels connus dans leur code Java en recourant à une fonction automatisée d'exploration de patterns appelée Reconnaissance architecturale.

Flux de travaux interdisciplinaire

Tandis que la collecte des exigences, la modélisation et l'implémentation font l'objet d'itérations successives au fil des différentes phases du cycle de vie du projet, plusieurs workflows (ou flux de travaux) peuvent se dérouler en continu tout au long de ce cycle.

Conditions d'utilisation | Retours d'informations
(C) Copyright IBM Corporation 2004, 2005. All Rights Reserved.