Mock: Encapsulating Subsystem Interactions


(Imagen: Diapostitivas del curso de IBM)

Why would you use subsystem interfaces rather than subsystem instances on sequence diagrams?

A. to make it easier to model subsystems during Subsystem Design
B. to make use-case realizations easier to change
C. to ease sequence diagram maintenance when message signatures change
D. To reduce the number of classes needed to implement the subsystem.


Para lograr la sustitución mutua de subsistemas que realizan la misma interfaz, sólamente las interfaces deben ser visibles en los diagramas de interacción; caso contrario todos los diagramas necesitarían cambiarse cuando un subsistema es sustituido por otro.

En un diagrama de interacción, enviar un mensaje a una interfaz significa que cualquier subsistema que realiza la interfaz puede sustituir a la interfaz en el diagrama.

En muchos casos, no existen mensajes salientes de la interfaz, dado que subsitemas diferentes que realizan la interfaz pueden enviar mensajes diferentes. Sin embargo, si se necesita señalar que mensajes deberían ser enviados de cualquier subsistema que realiza la interfaz, esos mensajes pueden originarse de la interfaz en el diagrama de secuencia.

Con este enfoque, nos centramos en los servicios al describir las interacciones, y no en como se implementan los servicios en los elementos de diseño. Esto se conoce como "Diseño por contrato", y es uno de los principios de desarrollo robusto de software usando mecanismos de abstracción y encapsulamiento.

La descripción de como se implementan los servicios es tema de las actividades de Diseño de Subsistemas (para los subsistemas de diseño) y de Diseño de Clases (para las clases de diseño).

Entonces, la B sería nuestra respuesta.

Basado en el material del curso DEV475: Mastering Object-Oriented Analysis and Design with UML 2.0

Pregunta tomada de Elite Certify

Publicar un comentario