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.
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.
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.
|
|