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.
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:
-
Cree diagramas de clase según sea necesario. Consulte
Adición de diagramas de clase a elementos de modelo.
-
Añada señales. Consulte
Creación y modificación de diagramas de clase .
-
Añada una descripción breve a cada elemento de diseño. Consulte
Documentación de elementos de modelo.
-
Añada relaciones de generalización entre señales, si procede.
Para obtener más información sobre diagramas de clase, consulte Modelado de estructura
estática by mediante diagramas de clase.
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 Montaje
de patrones y Aplicació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: Aplicació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".
-
Cree diagramas de clase según sea necesario. Consulte
Adición de diagramas de clase a elementos de modelo.
-
Añada subsistemas y clases. Consulte
Creación y modificación de diagramas de clase .
-
Añada una descripción breve a cada elemento de diseño. Consulte
Documentación de elementos de modelo .
-
(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
Relaciones de abstracción en el modelado UML.
-
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 Modelado 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 Modelado de estructura estática con diagramas de clase en
la ayuda en línea.
Los pasos siguientes se aplican a subsistemas de gran granularidad:
-
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
Adición de
interfaces a diagramas de modelado.
-
Añada dependencias de interfaz.
-
Correlacione subsistemas con interfaces añadiendo una relación de ejecución del subsistema a la interfaz.
-
Documente la interfaz, incluido el comportamiento necesario. Consulte
Documentación de elementos de modelo .
-
Añada operaciones a la interfaz. Consulte
Adición de operaciones a clasificadores en diagramas.
-
Añada una descripción a cada operación. Consulte
Documentación de elementos de modelo .
-
Añada parámetros a cada operación. Consulte
Adición de operaciones a clasificadores en diagramas.
-
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.
El modelado de cápsulas y protocolos no se soportan.
Tutoriales:
-
Aplicar
un patrón
Ejemplos:
-
Patrones:
Modelo UML simple
|