Roles en el Flujo de Trabajo de Diseño y Relaciones UML: Conceptos Clave

Trabajadores del Flujo de Trabajo (WF) de Diseño

A continuación, se describen los roles principales en el flujo de trabajo de diseño y los artefactos de los cuales son responsables:

1. Arquitecto

Es responsable de la integridad de los modelos de diseño y de despliegue, garantizando que sean correctos, consistentes y legibles en su totalidad. Puede incluirse un trabajador aparte para asumir las responsabilidades del subsistema de más alto nivel del modelo de diseño.

• Criterio de corrección: Los modelos son correctos cuando realizan la funcionalidad, y solo la funcionalidad, descrita en el modelo de casos de uso, en los requisitos adicionales y en el modelo de análisis.
• Responsabilidades: Define la arquitectura de los modelos de diseño y despliegue, asegurando la existencia de sus partes significativas.
• Limitaciones: No es responsable del desarrollo y mantenimiento continuos de los distintos artefactos del modelo de diseño.

2. Ingeniero de Casos de Uso

Es responsable de la integridad de una o más realizaciones de casos de uso-diseño, garantizando que cumplan los requisitos esperados. Una realización de caso de uso-diseño debe ejecutar correctamente el comportamiento de su correspondiente realización de caso de uso-análisis y del caso de uso original, sin añadir funcionalidades extra.

Nota: Este rol no es responsable de las clases, subsistemas, interfaces y relaciones de diseño utilizadas en la realización del caso de uso.

3. Ingeniero de Componentes

Define y mantiene las operaciones, métodos, atributos, relaciones y requisitos de implementación de una o más clases del diseño, garantizando que cada clase cumpla con los requisitos de las realizaciones de casos de uso en las que participa.

• Gestión de subsistemas: Puede mantener la integridad de uno o más subsistemas.
• Continuidad: Es recomendable que el ingeniero responsable de un subsistema también lo sea de sus elementos internos. Para un desarrollo uniforme, los artefactos de diseño deben conservarse en el flujo de trabajo de implementación, siendo implementados por el mismo ingeniero.

Comparativa de Relaciones en UML: Generalización, Realización y Composición

Herencia (Generalización)

• Características: Es un reúso de "caja blanca"; las clases heredadas no se trasladan a objetos.
• Ventajas: Se define estáticamente en tiempo de compilación, es sencilla de usar al estar permitida directamente por el lenguaje y facilita la modificación de la implementación utilizada.
• Desventajas: No se pueden cambiar las implementaciones heredadas en tiempo de ejecución. Las clases padre suelen definir parte de la representación física de sus subclases, lo que "rompe el encapsulamiento".

Realización

• Características: Se utiliza para relacionar una clase con una interfaz.
• Ventajas: Los clientes no necesitan conocer los tipos específicos de los objetos, solo deben adherirse a la interfaz esperada. Los clientes desconocen las clases concretas, interactuando únicamente con las clases abstractas que definen la interfaz.

Composición

• Características: Es un tipo de relación "todo-parte" donde el conjunto se compone de muchas partes. Es un reúso de "caja negra" que permite la delegación (hacer peticiones a otra clase sin romper el encapsulamiento).
• Ventajas: Se define dinámicamente en tiempo de ejecución mediante objetos que tienen referencias a otros. Se accede solo a través de interfaces, manteniendo el encapsulamiento. Cualquier objeto puede ser reemplazado en tiempo de ejecución por otro del mismo tipo, reduciendo las dependencias de implementación.
• Desventajas: A diferencia de la delegación pura, una implementación incorrecta de la composición puede comprometer el encapsulamiento.