Instrucciones de la herramienta: Identificación de elementos de diseño mediante Rational Systems Developer
Esta guía de la herramienta describe cómo identificar elementos de diseño mediante el entorno de modelado RSD.
Herramienta: Rational Systems Developer
Amplía: Identificación de elementos de diseño mediante la plataforma de desarrollo de software Rational
Relaciones
Elementos relacionados
Descripción principal

Visión general

En la guía de la herramienta se llevan a cabo los pasos siguientes para los guiones de uso que se van a diseñar en la iteración actual:

Información adicional sobre la herramienta

Los elementos de diseño significativos arquitectónicamente se pueden documentar en una vista lógica separada, que se mantiene mientras se identifican los elementos de diseño. La recomendación general es utilizar paquetes de <<perspectiva>>. Consulte Directrices de estructura de modelo para RSx para obtener más información sobre este tema.

Identificar sucesos y señales

Las características de los sucesos, también llamados desencadenantes en UML 2.0, se deben capturar según sea necesario para dirigir la identificación de los elementos de diseño que los manejan. Esta información se puede capturar de modo informal, por ejemplo, en un documento separado, en lugar de como parte de un modelo.

Los sucesos de comunicación asíncrona se pueden modelar como señales para expresar los datos que transmiten, o bien, para expresar relaciones entre señales como, por ejemplo, una relación de generalización. En los subpasos siguientes se describe cómo modelar señales:

  1. Cree diagramas de clase según sea necesario. Consulte icono de publicaciónAdición de diagramas de clase a elementos de modelo.
  2. Añada señales. Consulte icono de publicaciónCreación y modificación de diagramas de clase .
  3. Añada una descripción breve a cada elemento de diseño. Consulte icono de publicaciónDocumentación de elementos de modelo.
  4. Añada relaciones de generalización entre señales, si procede.  

Para obtener más información sobre diagramas de clase, consulte icono de publicaciónModelado de estructura estática by mediante diagramas de clase.

Identificar clases, clases activas y subsistemas

Por lo general, los elementos de diseño se crean de tres modos:

  • Ampliación de un patrón
  • Modelado
  • Codificación e ingeniería inversa 

Estas propuestas se explican en las secciones siguientes.

Ampliación de un patrón

Un patrón es una clase especial de transformación que se optimiza para la elaboración interactiva y por partes, principalmente en un metamodelo individual y dentro del mismo nivel de abstracción, y a menudo dentro del mismo modelo. Para obtener más información, consulte Mecanismos de análisis.

Consulte icono de publicaciónMontaje de patrones y icono de publicaciónAplicación de patrones en la ayuda en línea.

Modelado

Esta herramienta da soporte a un enfoque controlado por modelos respecto al desarrollo del software (consulte Desarrollo controlado por modelos y arquitectura controlada por modelo y Mecanismos de análisis), donde puede construir un conjunto de modelos que finalmente incluirá un modelo de diseño y artefactos de generación de implementaciones como, por ejemplo, el código 3GL, descriptores, etc. Estos se derivan del modelo de diseño mediante transformaciones. En algunos casos, las transformaciones de generación de código utilizarán las clases de análisis como entradas, pero principalmente serán controladas por elementos de diseño. Para obtener más información, consulte: icono de publicaciónAplicación de transformaciones.

En un enfoque de desarrollo tradicional, se crean diagramas de clase en el modelo de diseño para capturar elementos de diseño. Si decide mantener las clases de análisis, es posible que desee establecer rastreabilidad mediante dependencias de "rastreo".

  1. Cree diagramas de clase según sea necesario. Consulte icono de publicaciónAdición de diagramas de clase a elementos de modelo.
  2. Añada subsistemas y clases. Consulte icono de publicaciónCreación y modificación de diagramas de clase .
  3. Añada una descripción breve a cada elemento de diseño. Consulte icono de publicaciónDocumentación de elementos de modelo .
  4. (opcional) Añada rastreabilidad a las clases de análisis mediante dependencias de "rastreo" desde elementos de diseño a las clases de análisis en las que se basan. Consulte icono de publicaciónRelaciones de abstracción en el modelado UML.
  5. Organice los elementos de diseño en subsistemas y paquetes. Consulte la documentación técnica Directrices de estructura de modelo para RSx.

Para obtener más información sobre diagramas de clase, consulte icono de publicaciónModelado de estructura estática con diagramas de clase .

Codificación e ingeniería inversa

Nota: algunas capacidades de la herramienta mencionadas en esta sección no se soportan en RSM.

Un enfoque diferente es un enfoque en el que se tiene en cuenta el código en primer lugar. El código es el controlador principal porque ya existe (por ejemplo, en un ciclo de desarrollo en el que no se parte de cero) o el equipo debe tratar algunos riesgos de proyecto específicos codificando un prototipo para validar un concepto complejo. Como parte del soporte del Descubrimiento de arquitectura y de la Recuperación (consulte las directrices Análisis, control y descubrimiento de arquitectura), la función de visualización de código de la herramienta puede rellenar automáticamente diagramas de tema como, por ejemplo, la estructura del paquete, las características esenciales de la clase, árboles de herencia y colaboraciones. El objetivo de esta tarea no es sólo comprender el código existente, sino también extraer un modelo de la aplicación, el cual se puede utilizar junto con otros modelos específicos para generar la nueva versión de la aplicación, mediante transformaciones.

Una vez que haya generado o compuesto un diagrama UML de código existente, dispondrá de las opciones siguientes para aprovechar las representaciones de código como parte del modelo de diseño:

  • Recopile una representación UML de un elemento de código en el modelo de diseño, como un elemento de modelo semántico verdadero. Esto crea un nuevo elemento UML en el modelo de diseño que no tiene relación con el elemento de código recopilado. Sin embargo, sí contiene propiedades (por ejemplo, atributos y operaciones) que reflejan las propiedades del elemento de código recopilado. Puesto que se trata de un elemento semántico UML verdadero, el nuevo código se puede generar a partir de dicho elemento (es decir, tiene el mismo estado dentro del modelo de diseño que cualquier elemento de diseño definido a través del proceso de modelado desde cero descrito anteriormente.)
  • Coloque una referencia visual para el elemento de código en un diagrama que se encuentre en el modelo de diseño. Esta referencia no tiene significado semántico alguno dentro del modelo de diseño y no se generará código a partir de ésta. Se trata, como su nombre implica, de una simple referencia al elemento de código real. De todos modos, se pueden crear relaciones entre la referencia del código y los elementos de diseño semánticos del modelo de diseño. Dichas relaciones tiene un significado semántico dentro del modelo de diseño y afectan a la generación de código.

Para obtener más información, consulte icono de publicaciónModelado de estructura estática con diagramas de clase en la ayuda en línea.

Identificar interfaces del subsistema

Los pasos siguientes se aplican a subsistemas de gran granularidad:

  1. Para cada subsistema, identifique un conjunto de interfaces candidatas. Si ha creado anteriormente clases de análisis y ha realizado ejecuciones de guiones de uso de nivel de análisis, ahora decidirá el modo en que dichas operaciones deben agruparse y exponerse en forma de interfaces de componentes o servicios determinados. Añada interfaces a un diagrama de componente existente o cree nuevos diagramas de componente, según convenga. Consulte icono de publicaciónAdición de interfaces a diagramas de modelado.
  2. Añada dependencias de interfaz.  
  3. Correlacione subsistemas con interfaces añadiendo una relación de ejecución del subsistema a la interfaz.
  4. Documente la interfaz, incluido el comportamiento necesario. Consulte icono de publicaciónDocumentación de elementos de modelo .
  5. Añada operaciones a la interfaz. Consulte icono de publicaciónAdición de operaciones a clasificadores en diagramas.
  6. Añada una descripción a cada operación. Consulte icono de publicaciónDocumentación de elementos de modelo .
  7. Añada parámetros a cada operación. Consulte icono de publicaciónAdición de operaciones a clasificadores en diagramas.
  8. Organice las interfaces en paquetes.  

En UML 2.0, los subsistemas son componentes grandes y se pueden representar como clases estructuradas con puertos y/o interfaces. Consulte los temas UML 2.0 específicos de la ayuda en línea. 

Identificar protocolos de cápsula

El modelado de cápsulas y protocolos no se soportan.

Información adicional sobre la herramienta

Tutoriales:

  • icono de publicaciónAplicar un patrón

Ejemplos:

  • icono de publicaciónPatrones: Modelo UML simple