Tarea: Diseño de la cápsula
En esta tarea se describen las características del diseño de la cápsula.
Objetivo
  • Elaborar y perfeccionar las descripciones de una cápsula.
Relaciones
RolesPrincipal: Adicional: Asistencia:
EntradasObligatoria: Opcional: Externa:
  • Ninguno
Salidas
Descripción principal

Las cápsulas se utilizan para definir hebras concurrentes de ejecución en el sistema. Las cápsulas pueden anidarse a una profundidad arbitraria, así como tener asociaciones con clases de diseño (pasivas). Esta actividad se realiza una vez para cada cápsula, incluidas las cápsulas nuevas identificadas dentro del ámbito de esta tarea.

 Representación UML 2.0

Tenga en cuenta que la representación actual de RUP para cápsulas se basa en la notación UML 1.5. La mayor parte de esto se puede representar en UML 2.0 mediante Concepto: Clase estructurada.

Consulte el apartado Diferencias entre UML 1.x y UML 2.0 para obtener más información.

Pasos
Crear puertos y vincularlos a protocolos

Considere las responsabilidades de la cápsula, creando un conjunto inicial de clases de puerto. Estas clases de puerto representan las 'interfaces' con la cápsula. Las clases de puerto representan la realización de un Producto de trabajo: Protocolo, que a su vez representa un conjunto de señales de entrada y salida que se utilizan para la comunicación con las cápsulas.

Al crear puertos, considere la Lista de comprobación: Protocolo para determinar si el protocolo es apropiado. El puerto debe reflejar un conjunto singular de responsabilidades relacionadas; tener un protocolo de ámbito similar permite su reutilización en diversas cápsulas. Una vez que se ha seleccionado el protocolo apropiado, vincule el puerto con el protocolo apropiado.

Validar las interacciones de la cápsula

Una vez que los puertos se han vinculado a los protocolos, el comportamiento externo de la cápsula debe evaluarse y validarse. Utilizando técnicas de ensayo manuales o herramientas de simulación automatizadas, pruebe el comportamiento de la cápsula simulando los sucesos que ejecutarán el comportamiento de la cápsula. La validación también tendrá en cuenta las cápsulas que interactúan con la cápsula que se está diseñando. Utilizando herramientas automatizadas, escriba código de fragmento dentro de la cápsula para permitir que se puedan probar los puertos. Cuando se detecten errores en la definición de protocolo o puerto o en las responsabilidades de la cápsula, realice los cambios apropiados en las definiciones de cápsula, puerto y protocolo.

Definir máquina de estado de cápsula

Una vez que se han validado los puertos y protocolos de la cápsula, defina el comportamiento interno de la cápsula. El comportamiento de la cápsula se define utilizando un diagrama de gráfico de estados. Referencia: Directriz: Diagrama de gráfico de estados. Se puede obtener información general sobre la cápsula en la Directriz: Cápsula , Lista de comprobación: Cápsula.

Definir estado

En primer lugar, identifique los estados en los que la cápsula puede existir. Los estados deben ser exclusivos (una cápsula no puede estar en dos estados al mismo tiempo) y también deben ser descriptivos. Para obtener más información, consulte las directrices y los puntos de control correspondientes.

Definir transiciones de estado

Una vez que se han definido los estados, considere las transiciones entre los estados. El código de transición se debe leer como seudocódigo de aplicación de alto y debe estar formado principalmente por llamadas de servicio de sistema operativo en tiempo real como, por ejemplo, servicios de trama, servicios de tiempo, operaciones de puerto, operaciones de cápsula y operaciones de clases pasivas.

Al añadir código de detalle a una transición de cápsula:

  • Si el código puede ser útil en otras transiciones, considere la posibilidad de delegarlo a una operación de cápsula.
  • Considere si el código implementa funciones que se ajustan a la responsabilidad de la cápsula.

Al definir una operación de cápsula:

  • Considere si la función puede ser utilizable en cualquier momento desde cualquier transición de la cápsula y si alguno de los trabajos que se están realizando puede ser útil alguna vez en otro lugar del sistema. En caso afirmativo, considere la posibilidad de delegarlo a una función de clase pasiva.
  • Si el código es demasiado específico de la aplicación para poder almacenarse en una determinada clase de datos, considere la posibilidad de crear una clase de datos adicional como abstracción de dicho código.
  • Si el código permite manipular la estructura de datos (p.ej., manteniendo listas) o realiza cálculos complejos (más de 1 línea), debe forzarse a una clase de datos.
Definir requisitos sobre clases pasivas

En función de las máquinas de estado de cápsula, examine las clases pasivas a las que hace referencia la cápsula. Si hay nuevos requisitos sobre estas clases, se deberán generar solicitudes de cambio para efectuar los cambios necesarios. Si se han identificado nuevas clases, deben recopilarse los requisitos sobre estas clases (más concretamente las operaciones necesarias sobre ellas) y deben crearse las clases. Estas clases se describirán con más detalle en la Tarea: Diseño de clase.

Introducir la herencia de cápsula

La herencia de cápsula se utiliza para implementar la generalización-especialización, hacer uso del polimorfismo y reutilizar la implementación. La palabra clave aquí es 'implementación'. Se trata de una técnica que se utiliza principalmente para reutilizar la estructura interna de las cápsulas y no el comportamiento externo de las cápsulas.

La herencia a menudo se aplica incorrectamente para lograr algo que podría haberse conseguido más fácilmente utilizando técnicas de diseño más simples.

Utilización de la herencia para la generalización-especialización

Existes tres tipos de herencia. Listadas desde la menos compleja (más deseable) a la más compleja (menos deseable), son las siguientes:

  • Herencia de interfaz: sólo hereda puertos y protocolos; es el tipo de herencia más deseable
  • Herencia estructural: hereda la interfaz además de las jerarquías de la contención estructural (útil para infraestructuras)
  • Herencia de comportamiento: además de la herencia de interfaz y estructural, también reutiliza el código de comportamiento y las máquinas de estado

La herencia estructural y la herencia de comportamiento plantean algunos problemas:

  • El grado muy fuerte de acoplamiento que proporciona la herencia hace que los cambios se propaguen en cascada hasta las subclases cuando se realizan cambios en las superclases.
  • La necesidad de alterar temporalmente y suprimir el comportamiento y la estructura de superclase en las subclases indica un uso inapropiado de la herencia (normalmente para la reutilización táctica de código). Una estrategia más apropiada es la refactorización de clases y cápsulas y el uso apropiado de la delegación.
  • La herencia significa subir las decisiones de diseño hasta la jerarquía de clase, lo que provoca dependencias de compilación y diseño indeseables.  

Otros problemas son:

  • Las decisiones pueden no ser apropiadas en todas las situaciones de uso.
  • La introducción de la herencia dificulta la reutilización ya que los elementos de diseño están más estrechamente acoplados.
  • El diseño se hace más frágil ya que cualquier nuevo requisito que invalide la decisión provoca problemas importantes.
  • El diseño tiene que hacerse sumamente flexibles para compensar, lo cual a menudo es difícil. Por ello, el diseño de infraestructuras reutilizables supone un esfuerzo enorme.

Todos los diseños que contienen estructura/comportamiento tienen decisiones y suposiciones incorporadas (ya sea explícitas o implícitas). La pregunta clave que debe hacerse es: ¿está completamente seguro que la decisión/suposición será siempre válida? Si no lo lo está, ¿qué puede hacer para eliminarla o permitir que cambie?

Validar el comportamiento de la cápsula

Como paso final, el comportamiento de la cápsula debe evaluarse y validarse. Utilizando técnicas de ensayo manuales o herramientas de simulación automatizadas, debe probarse el comportamiento de la cápsula simulando los sucesos que ejecutarán el comportamiento de la cápsula. Además, debe validarse la estructura interna de la cápsula, garantizando que se valida no sólo el comportamiento externo sino también la implementación interna de dicho comportamiento. Utilizando herramientas automatizadas, es posible que se necesite escribir código de fragmento para similar la implementación de clases de datos pasivas y cápsulas externas con las que la cápsula interactúa. Se deben documentar los defectos detectados y se deben realizar los cambios apropiados en las definiciones de la cápsula.

Propiedades
Varias apariciones
Condicionado por sucesos
Continuo
Opcional
Planeado
Se puede repetir
Más información