Roles y Responsabilidades en el Diseño de Software

Arquitecto

El arquitecto es responsable de la integridad de los modelos de diseño y despliegue, garantizando que los modelos 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.

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.

El arquitecto también es responsable de la arquitectura de los modelos de diseño y despliegue, de la existencia de sus partes significativas para la arquitectura.

El arquitecto no es responsable del desarrollo y mantenimiento continuos de los distintos artefactos del modelo de diseño.

Ingeniero de Casos de Uso

El ingeniero de casos de uso es responsable de la integridad de una o más realizaciones de casos de uso-diseño, y debe garantizar que cumplen los requisitos que se esperan de ellos.

Una realización de caso de uso-diseño debe realizar correctamente el comportamiento de su correspondiente realización de caso de uso-análisis del modelo de análisis, así como el comportamiento de su correspondiente caso de uso del modelo de casos de uso, y solo esos comportamientos.

El ingeniero de casos de uso no es responsable de las clases, subsistemas, interfaces y relaciones de diseño que se utilizan en la realización del caso de uso.

Ingeniero de Componentes

El 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 del diseño cumple los requisitos que se esperan de ella según las realizaciones de caso de uso en las que participa.

El ingeniero de componente puede mantener también la integridad de uno o más subsistemas. Suele ser adecuado hacer que el ingeniero de componentes responsable de un subsistema sea también responsable de los elementos del modelo que este último contiene.

Para conseguir un desarrollo uniforme y sin discontinuidades, lo natural es que los artefactos del modelo de diseño se conserven en el flujo de trabajo de implementación y que los implemente el mismo ingeniero de componentes.

Cuadro Comparativo de Relaciones de Generalización, Realización y Agregación/Composición

Generalización (Herencia)

• Características: Reúso de caja blanca, hereda clases que no se trasladan a objeto.
• Ventajas: Se define estáticamente en tiempo de compilación, es sencilla de usar y hace más fácil modificar la implementación que está siendo utilizada.
• Desventajas: No se pueden cambiar las implementaciones heredadas de las clases padre en tiempo de ejecución, la herencia rompe el encapsulamiento.

Realización

• Características: Se utiliza para relacionar una clase con una interfaz.
• Ventajas: Los clientes no tienen que conocer los tipos específicos de los objetos que usan, basta con que se adhieran a la interfaz que esperan los clientes.

Agregación/Composición

• Características: Es un tipo de relación todo parte en donde el conjunto se compone de muchas partes. Es reúso de caja negra, permite la delegación.
• Ventajas: Se define dinámicamente en tiempo de ejecución, se accede solo a través de sus interfaces, no rompe el encapsulamiento, cualquier objeto puede ser reemplazado en tiempo de ejecución por otro siempre que sean del mismo tipo.
• Desventajas: Rompe el encapsulamiento.