Guide d'utilisation de l'outil: Identification des éléments de conception à l'aide de la plateforme Rational Software Development
Ce guide d'utilisation de l'outil explique comment identifier des éléments de conception à l'aide de l'environnement de modélisation SDP.
Description principale

Présentation

Dans ce guide d'utilisation de l'outil, les étapes suivantes sont exécutées pour chaque cas d'utilisation à concevoir dans l'itération en cours :

Informations supplémentaires sur l'outil

Les éléments de conception significatifs du point de vue architectural peuvent être consignés dans une vue logique séparée, qui est maintenue au fur et à mesure que les éléments de conception sont identifiés. La recommandation générale est d'utiliser des packages de <<perspective>>. Voir Instructions relatives aux structures de modèles pour RSx pour plus d'informations sur ce sujet.

Identifier les événements/déclencheurs et les signaux

Les caractéristiques des événements, aussi appelés déclencheurs dans UML 2.0, doivent être consignées selon les besoins pour identifier les éléments de conception qui les traitent. Ces informations peuvent être consignées de manière informelle, par exemple dans un document séparé, au lieu de faire partie d'un modèle.

Les événements de communication asynchrone peuvent être modélisés sous forme de signaux pour spécifier les données contenues ou les relations entre les signaux, comme par exemple la généralisation. Les sous-étapes suivantes expliquent comment modéliser les signaux :

  1. Créez des diagrammes de classes selon les besoins. Voir manuel d'aideAdding Class Diagrams to Model Elements (Ajout de diagrammes de classes aux éléments de modèle).
  2. Ajoutez des signaux. Voir manuel d'aideCreating and Modifying Class Diagrams (Création et modification des diagrammes de classes).
  3. Ajoutez une brève description à chaque élément de conception. Voir manuel d'aideDocumenting Model Elements (Documentation des éléments de modèle).
  4. Ajoutez des relations de généralisation entre les signaux, si cela est utile.  

Pour plus d'informations sur les diagrammes de classes, voir manuel d'aideModeling Static Structure by Using Class Diagrams (Modélisation de la structure statique à l'aide de diagrammes de classes).

Identifier les classes, les classes actives et les sous-systèmes

Les éléments de conception sont généralement créés des trois manières suivantes :

  • Extension d'un pattern
  • Modélisation
  • Codage et génération de code 

Ces approches sont expliquées dans les sections ci-après.

Extension d'un pattern

Un pattern est un type spécifique de transformation optimisé pour une élaboration interactive, par morceaux, principalement dans un seul métamodèle, de niveau d'abstraction équivalent, et souvent au sein du même modèle. Pour plus d'informations, Voir Mécanismes d'analyse.

Voir manuel d'aideAuthoring Patterns (Création de patterns) et manuel d'aideApplying Patterns (Application de patterns) dans l'aide en ligne.

Modélisation

Cet outil prend en charge une approche guidée par modèle pour le développement logiciel (Voir Développement guidé par modèle et architecture guidée par modèle et Mécanismes d'analyse), dans laquelle vous construisez un ensemble de modèles qui inclut un modèle de conception et génère des artefacts d'implémentation comme le code 3GL, les descripteurs etc. Ces derniers sont dérivés à partir du modèle de conception à l'aide des transformations. Dans certains cas, les transformations qui génèrent les codes prendront comme entrée les classes d'analyse, mais ils seront principalement guidés par les éléments de conception. Pour plus d'informations, voir : manuel d'aideApplying Transformations (Application des transformations).

Dans une approche de développement traditionnelle, vous créez des diagrammes de classes dans le modèle de conception afin de consigner les éléments de conception. Si vous décidez de maintenir les classes d'analyse, vous souhaiterez peut-être établir une traçabilité en utilisant des dépendances de "trace" par rapport aux classes d'analyse.

  1. Créez des diagrammes de classes selon les besoins. Voir manuel d'aideAdding Class Diagrams to Model Elements (Ajout de diagrammes de classes aux éléments de modèle).
  2. Ajoutez des sous-systèmes et des classes. Voir manuel d'aideCreating and Modifying Class Diagrams (Création et modification de diagrammes de classes).
  3. Ajouter une brève description à chaque élément de conception. Voir manuel d'aideDocumenting Model Elements (Documentation des éléments de modèle).
  4. (facultatif) Ajoutez une traçabilité aux classes d'analyse, en utilisant des dépendances de "trace" de vos éléments de conception aux classes d'analyse sur lesquelles elles se basaient. Voir manuel d'aideAbstraction Relationships in UML Modeling (Relations d'abstraction dans la modélisation UML).
  5. Organisez les éléments de conception en sous-systèmes et en packages. Consultez le livre blanc Instructions relatives aux structures de modèles pour RSx.

Pour plus d'informations sur les diagrammes de classes, Voir manuel d'aideModeling Static Structure with Class Diagrams (Modélisation de la structure statique avec des diagrammes de classes).

Code et génération de code

Remarque : certaines fonctions de l'outil mentionnées dans cette section ne sont pas prises en charge dans RSM.

Une approche différente est l'approche orientée code : le code est le moteur principal, soit parce qu'il existe déjà (par exemple dans un cycle de développement déjà existant), soit parce que l'équipe doit traiter des risques liés au projet en codant un prototype pour valider un concept complexe. Dans le cadre de la prise en charge de la reconnaissance et de la récupération de l'architecture (voir les instructions relatives à la reconnaissance, à l'analyse et au contrôle de l'architecture), la fonction de l'outil qui permet de visualiser le code peut remplir automatiquement les diagrammes de rubrique, comme la structure de package, les éléments internes de classe, les arborescences d'héritage et les collaborations. L'objectif de cette tâche n'est pas seulement de comprendre le code existant, mais également d'extraire un modèle de l'application, qui peut être utilisé en relation avec d'autres modèles spécifiques pour générer la nouvelle version de l'application, en utilisant des transformations.

Après avoir généré ou composé un diagramme UML de code existant, plusieurs options s'offrent à vous pour tirer parti des représentations de code dans le cadre de votre modèle de conception :

  • Recueillez une représentation UML d'un élément de code dans votre modèle de conception en tant que véritable élément de modèle sémantique. Cela crée un nouvel élément UML dans le modèle de conception qui n'a pas de lien avec l'élément de code recueilli. Il a cependant des propriétés (d'attributs et d'opérations d'instance) qui reflètent les propriétés de l'élément de code recueilli. Dans la mesure où il s'agit d'un véritable élément sémantique UML, on peut générer un nouveau code à partir de cet élément (c'est-à-dire qu'il a le même statut dans le modèle de conception que tout élément de conception défini par le processus de modélisation inédit décrit ci-dessus.)
  • Appliquez une référence visuelle à l'élément de code dans un diagramme situé dans le cadre de votre modèle de conception. Cette référence n'a pas de signification sémantique dans le modèle de conception et aucun nouveau code ne sera généré à partir d'elle. Il ne s'agit, comme son nom l'indique, que d'une référence au véritable élément de code. Cependant, vous pouvez dessiner des relations entre la référence de code et les éléments de conception sémantiques dans le modèle de conception. Ces relations ont une signification sémantique dans le modèle de conception, et elles ont une influence sur la génération de code.

Pour plus d'informations, consultez la rubrique manuel d'aideModeling Static Structure with Class Diagrams (Modélisation d'une structure statique avec des diagrammes de classes) dans l'aide en ligne.

Identifier les interfaces de sous-système

Les étapes suivantes s'appliquent aux systèmes à forte granularité :

  1. Pour chaque sous-système, identifiez un ensemble d'interfaces potentielles. Si vous avez précédemment créé des classes d'analyse et effectué des réalisations de cas d'utilisation de niveau d'analyse, vous devez à présent choisir la façon dont les opérations doivent être regroupées et décrites en tant qu'interfaces de composants ou de services spécifiques. Ajoutez des interfaces à un diagramme de composants existant ou créez des nouveaux diagrammes de composants si nécessaire. Voir manuel d'aideAdding Interfaces to Modeling Diagrams (Ajout d'interfaces aux diagrammes de modélisation).
  2. Ajoutez des dépendances d'interface. 
  3. Mappez les sous-systèmes aux interfaces en ajoutant une relation de réalisation du sous-système à l'interface.
  4. Documentez l'interface en incluant le comportement requis. Voir manuel d'aideDocumenting Model Elements (Documentation des éléments de modèle).
  5. Ajoutez des opérations à l'interface. Voir manuel d'aideAdding Operations to Classifiers in Diagrams (Ajout d'opérations aux discriminants dans les diagrammes).
  6. Ajoutez une description à chaque opération. Voir manuel d'aideDocumenting Model Elements (Documentation des éléments de modèle).
  7. Ajoutez des paramètres à chaque opération. Voir manuel d'aideAdding Operations to Classifiers in Diagrams (Ajout d'opérations aux discriminants dans les diagrammes).
  8. Organisez les interfaces en packages. 

Dans UML 2.0, les sous-systèmes sont des composants de grande taille et doivent être représentés comme des classes structurées avec des ports et/ou des interfaces. Voir les rubriques de l'aide en ligne spécifiques à UML 2.0. 

Identifier les protocoles de capsule

La modélisation de capsule et de protocole n'est pas prise en charge.

Informations supplémentaires sur l'outil

Tutoriels :

  • manuel d'aideApply a Pattern (Appliquer un pattern)

Exemples :

  • manuel d'aidePatterns - Simple UML Model (Patterns - Modèle UML simple) 

Plus d'informations