IIE ­ Instituto de Ingeniería Eléctrica.DesaSoft ­ Desarrollo de Software para Ingeniería Eléctrica.Guías de clase.   Parte II: Ingeniería de Software.

Asignación de responsabilidades:Patrones de Diseño.

Índice de contenido

Asignación de responsabilidades:Patrones de Diseño...........................................................................................................................1

Responsabilidad......................................................................................................................1Asignación de responsabilidades.............................................................................................1Patrones..................................................................................................................................2Patrón Experto.........................................................................................................................2Patrón Creador........................................................................................................................4Patrón Bajo Acoplamiento.......................................................................................................4Patrón Alta Cohesión...............................................................................................................6Patrón Controlador..................................................................................................................7Realización de los casos de uso...............................................................................................8Referencias y lecturas recomendadas.......................................................................................9

Lecturas recomendadas..................................................................................................9Referencias.....................................................................................................................9

Responsabilidad.

Junto con la elección de clases conceptuales por vía de la abstracción, la asignación de responsabilidades es la habilidad más crítica en el análisis y diseño del software.

En UML se define una responsabilidad como un contrato u obligación asumidas por un objeto como parte de su comportamiento. Las responsabilidades son de dos tipos básicos:

• responsabilidad "hacer" de un objeto; • hacer algo el objeto mismo, como realizar un cálculo, crear otro objeto o establecer una 

asociación con otro objeto. • iniciar una acción en otro objeto. • controlar o coordinar acciones en otros objetos.

• responsabilidad "conocer" de un objeto: • conocer sus datos encapsulados (atributos privados). • conocer otros objetos relacionados con él. • conocer cosas que puede derivar o calcular. 

Las responsabilidades se implementan a través de métodos. Los métodos pueden actuar solos o requerir la colaboración de otros métodos del mismo u otros objetos. Los diagramas de interacción muestran las responsabilidades de los objetos; al crear los diagramas de interacción se está asignando responsabilidades a los objetos incluidos en el diagrama.

Asignación de responsabilidades.

Las responsabilidades a asignar surgen de los diagramas de interacción: los mensajes a los objetos implican asignación de responsabilidad a esos objetos, que deberán cumplir con lo pedido en el mensaje. Si ya existe un Diagrama de Clases de Diseño, se busca en él para determinar la o las clases que deberán tener asignadas responsabilidades para cumplir con la tarea. Si no aparece 

1 de 9

allí nada apropiado, o si recién comienza el diseño y se tiene un diagrama de clases mínimo, recurrir al Modelo de Dominio, creando, si es necesario, nuevas clases en el Diagrama de Clases de Diseño. Recordemos una vez más que el proceso de creación de los diagramas es de vaivén, se va completando algo de uno, luego algo de otro, en la medida en que se va armando la solución, cuidando de mantener la coherencia entre los diferentes diagramas.

Patrones.

Los años de práctica en el desarrollo de software han mostrado la existencia de problemas típicos que se dan una y otra vez en diferentes situaciones. El ensayo de diversas soluciones a estos problemas típicos ha llevado a establecer soluciones que se han vuelto también típicas por su probada confiabilidad. Asimismo aparecen principios generales, estilos o guías que han probado ser útiles en el desarrollo. Cuando se escriben de manera estructurada y se reúne un conjunto de estos principios, problemas y soluciones, se les llama patrones de diseño o simplemente patrones.

Un patrón es una pareja problema / solución, designada por un nombre, escrita en forma estructurada, aplicable en un nuevo contexto en el cual se reconoce el mismo problema; el patrón incluye recomendaciones para su empleo, una discusión sobre su alcance, limitaciones y uso; puede también incluir ejemplos.

Los patrones reúnen conocimiento existente, no crean nada nuevo; esto constituye su principal virtud, registran una solución probada, válida y efectiva para un problema corriente. Un patrón recoge la experiencia de muchos desarrolladores a lo largo de años en la búsqueda de solución a un problema de aparición reiterada.

Ejemplo simplificado de un patrón:

Nombre: Experto en Información.Problema: ¿Cuál es el principio básico para asignar responsabilidades a los objetos?Solución: Asignar una responsabilidad a la clase que tiene la información necesaria para 

cumplirla.

Los siguientes patrones constituyen principios generales para la asignación de responsabilidades:

• Experto en información. • Creador. • Alta cohesión. • Bajo acoplamiento. • Controlador. 

Patrón Experto.

Nombre: Experto en Información (o Experto).Problema: ¿Cuál es el principio básico para asignar responsabilidades a los objetos?Solución: Asignar una responsabilidad a la clase que tiene la información necesaria para 

cumplirla. Esta clase es el "experto en información".Ejemplo. Supermercado. ¿A qué clase debería asignarse la responsabilidad de conocer el total 

de una venta? Siguiendo el patrón Experto debe buscarse aquella clase que tiene la información necesaria para calcular este total, o que más fácilmente puede acceder a ella.

• la clase Venta no tiene conocimiento directo del total de la venta, pero sí de las clases LineaDeVenta que la componen. 

• la clase LineaDeVenta conoce la cantidad, aunque no el precio, pero conoce la EspecificacionDeProducto asociada a esa línea de venta, donde sí está el precio. 

• la EspecificacionDeProducto conoce todo lo referente al artículo consignado en la LineaDeVenta. 

En consecuencia, la responsabilidad de obtener el total de una venta implica la siguiente 

2 de 9

asignación de responsabilidades:• la EspecificacionDeProducto debe conocer el precio del artículo. • la LineaDeVenta debe conocer el monto de la línea de venta (cantidad * precio). • la Venta debe conocer el total de la venta (suma de montos de todas las líneas de venta 

componentes).El empleo del patrón experto ha asignado responsabilidades a las tres clases.Discusión: el cumplimiento de una responsabilidad requiere muchas veces información dispersa 

en otras clases de objetos; existen expertos en información parcial que deberán colaborar en la tarea. Esta colaboración genera un intercambio de mensajes entre los objetos involucrados.

Contraindicaciones: no siempre la solución del patrón Experto es la más conveniente; la aplicación del patrón Experto puede violar otros patrones como los de acoplamiento y cohesión (ver más adelante), mezclando funciones dispares o duplicando funciones. Estos problemas se atenúan respetando el principio de diseño arquitectónico de mantener separados los aspectos básicos del sistema: la lógica de la aplicación, el manejo de la base de datos, la interfaz gráfica de usuario, las comunicaciones... son áreas naturales con sus propias especializaciones que no conviene mezclar. 

Beneficios:• se mantiene el encapsulamiento de la información: los objetos usan antes que nada su propia 

información. • se distribuye el comportamiento sólo entre clases que contienen algo de la información 

requerida. 

Clases del análisis (conceptuales).

Clases del diseño (clases de software). Asignación de responsabilidades y modificación de diagramas.

3 de 9

Patrón Creador.

Nombre: Creador.Problema: ¿Quién debe ser responsable de la creación de una nueva instancia de una clase (un 

nuevo objeto)?Solución: asignar a la clase B la responsabilidad de crear una instancia de la clase A si se 

cumple una o más de las condiciones siguientes:• B agrega objetos de clase A (es una agregación de objetos de clase A).• B contiene objetos de clase A.• B registra objetos de clase A.• B usa estrechamente objetos de clase A.• B tiene los datos de inicialización necesarios para construir un objeto de clase A.Si se cumple una o más de estas condiciones B es un Creador de A. Las condiciones de mayor 

relevancia son la de agregación (B agrega objetos de clase A) y la de contenido (B contiene objetos de clase A).

Ejemplo. Supermercado. ¿Qué clase debería crear objetos de la clase LineaDeVenta? La clase Venta agrega objetos LineaDeVenta, por patrón Creador las LineaDeVenta deben ser creadas por Venta. Análogamente, por patrón Creador, los objetos EspecificacionDeProducto deben ser creados por Catalogo.

Discusión: el patrón Creador sugiere que una clase contenedora, o una clase de registro, son buenas candidatas para asignar la responsabilidad de creación de los objetos que contiene o registra.

Contraindicaciones: cuando la creación de un objeto es muy complicada conviene delegar la creación a una clase auxiliar denominada Factoría en lugar de usar directamente lo sugerido por el patrón Creador. Factoría es un patrón propuesto en el libro “Design Patterns” [Gamma1995], que popularizó el uso de patrones.

Beneficios: tiende a mantener un bajo acoplamiento, una mínima dependencia de otras clases clases.

Aplicación del patrón Creador para asignación de responsabilidad en la creación de una LineaDeVenta.

Patrón Bajo Acoplamiento.

Problema: ¿Cómo diseñar para obtener baja dependencia entre clases, poder realizar cambios con mínimo impacto, e incrementar la reutilización? En otras palabras, ¿cómo diseñar con bajo 

4 de 9

acoplamiento?El acoplamiento es una medida de la dependencia que tiene un elemento respecto a otros. Si un 

elemento depende fuertemente de otros tiene alto acoplamiento, si depende poco o nada, el acoplamiento es bajo. Es deseable un acoplamiento bajo, porque limita la cantidad de otros elementos que hay que tocar al hacer un cambio, favorece la reutilización del elemento en otras situaciones, facilita la comprensión y mantiene todo el diseño mejor separado, con un diseño más modular.El bajo acoplamiento es un principio de diseño; no puede considerarse independientemente de otros principios como el de Alta Cohesión o patrones como el Experto. Como principio, debe tenerse presente al encarar el diseño.

Solución: asignar una responsabilidad intentando mantener un acoplamiento bajo.Ejemplo. Supermercado. Consideremos las clases Sesión, Venta y Pago. Las ventas se realizan 

durante una sesión de la caja, las ventas quedan registradas en la sesión, hay una asociación 1 – 0..n de Sesion a Venta. ¿Quién debe crear Pago? Como Sesion registra toda las ventas, el patrón Creador podría sugerir que la creación de Pago fuera hecha por Sesion, y luego debe asociarse Pago a Venta. Esta solución acopla la clase Sesion con la clase Pago, Sesion debe conocer Pago. Una solución alternativa es confiar la creación de Pago a Venta. En este caso, Sesion mantiene acoplamiento sólo con Venta, y Venta con Pago. La creación de Pago no incrementa el acoplamiento de Sesion, que podría reusarse para manejar otros tipos de sesión que no requieran pagos; en cambio, ¡toda venta requiere un pago!

Discusión: el bajo acoplamiento es un principio evaluativo, no sugiere directamente una asignación de responsabilidad, sino que ofrece una guía para evaluar diferentes alternativas en la asignación de responsabilidades. Debe tenerse en cuenta en todo el diseño.

Una subclase tiene un fuerte acoplamiento con su superclase. La consideración de herencia debe estar bien justificada por la abstracción de características o comportamiento comunes para la creación de una superclase.

La exageración del bajo acoplamiento lleva a un diseño prácticamente inconexo con objetos sobresaturados, donde cada uno debe hacer muchas cosas para no depender de los otros, cosas que pueden no ser relevantes para su función; hace aparecer también otros objetos muy pasivos, como ser repositorios de datos que no hacen prácticamente nada. El acoplamiento en sí no es un problema, el problema es el alto acoplamiento; un cierto grado de acoplamiento es necesario para obtener un diseño equilibrado.

Contraindicaciones: no da problemas el alto acoplamiento entre elementos estables y generalizados, como las bibliotecas; no es problema, en un programa Java, depender de las clases contenidas en las bibliotecas de Java.

Beneficios:• puede cambiarse un componente sin involucrar otros. • el componente es entendible por sí. • el componente puede reutilizarse por sí solo en otros diseños.

Alto acoplamiento, baja cohesión: peor. Bajo acoplamiento, alta cohesión: mejor.

5 de 9

Patrón Alta Cohesión.

Problema: ¿Cómo diseñar para mantener las clases limitadas a realizar tareas funcionalmente relacionadas entre sí, en torno a un interés común, para lograr un buen manejo de la complejidad del problema total? En otras palabras, ¿cómo diseñar con alta cohesión?

La cohesión es una medida del relacionamiento interno de las responsabilidades de un elemento, de su pertenencia a una misma área de interés. Un elemento con pocas responsabilidades, todas relacionadas entre sí, tiene alta cohesión. Una clase con baja cohesión realiza muchas tareas muy diversas, una gran cantidad de cosas, tareas que tienen poco que ver entre sí. Las clases con baja cohesión son propensas a padecer diversos problemas:

• son difíciles de entender y difíciles de mantener, tienden a ser grandes.• son difíciles de reutilizar en otros diseños.• están afectadas constantemente por los cambios, porque hacen demasiado.Las clases con baja cohesión han recibido excesivas responsabilidades, responsabilidades que 

deberían haber recaído sobre otros elementos; resultan también de una abstracción pobre, donde no se han diferenciado suficientes áreas o niveles de abstracción.

La alta cohesión es un principio de diseño; no puede considerarse independientemente de otros principios como el de bajo acoplamiento o patrones como el Experto. Como principio, debe tenerse presente al encarar el diseño.

Obsérvese que la cohesión es una propiedad interna de un elemento, no mira fuera del propio elemento, en tanto el acoplamiento es una propiedad externa a un elemento, se fija en su relacionamiento con otros elementos y no en su interior.

Solución: asignar responsabilidades a un elemento intentando mantener su cohesión alta.Ejemplo. Supermercado. El mismo ejemplo de Sesion, Venta y Pago ilustra la cohesión. Asignar 

a Sesion la creación de Pago baja su cohesión, lo obliga a hacer una tarea poco relacionada con su objetivo específico de mantener registro de las ventas; se le agrega una tarea de un área que no le es funcionalmente afín. La solución alternativa de confiar la creación de Pago a Venta mantiene la cohesión de Sesion alta, y también mantiene alta la cohesión de Venta; es funcionalmente afín a la venta manejar el pago.

Discusión: la alta cohesión, al igual que el bajo acoplamiento, es un principio evaluativo, no sugiere directamente una asignación de responsabilidad, sino que ofrece una guía para evaluar diferentes alternativas en la asignación de responsabilidades. Debe tenerse en cuenta en todo el diseño.

Criterio práctico: una clase con alta cohesión contiene un número limitado de métodos, todos realizando operaciones relativas a una misma área de interés o tarea general; no realiza demasiadas cosas, más bien colabora con otras clases para la realización de tareas complejas.

Contraindicaciones:• Algunas tareas de excesiva especialización como el acceso a base de datos puede requerir la 

creación de una clase con multiplicidad de tareas relativas a la base de datos, cosa que puede involucrar un número considerable de métodos. En este caso, una clase especializada en acceso a base de datos puede estar justificada; sería poco práctico repartir el manejo de la base de datos por todas las clases que deben insertar, modificar o consultar la base de datos. Concentrando las funciones de base de datos en una clase especial permite a los administradores de bases de datos tener todas sus herramientas concentradas en esta clase "interfaz"; las otras clases invocan los métodos de la clase interfaz, quien a su vez se comunica con la base de datos. 

• Otro ejemplo son los sistemas distribuidos, en los que para minimizar la comunicación un elemento realiza más de lo que debiera; en estos casos la violación (mesurada) del principio de alta cohesión puede aparecer justificada.

Beneficios:• el diseño es más claro y fácil de entender.• los cambios se realizan más fácilmente.

6 de 9

• frecuentemente lleva a un menor acoplamiento.• aumenta la posibilidad de reutilización del elemento, por el alto relacionamiento funcional de 

las tareas realizadas.

Patrón Controlador.

Nombre: Controlador.Problema: ¿Cómo asignar responsabilidades para manejar eficientemente los eventos de 

entrada al sistema?Un evento de entrada al sistema o evento del sistema es una acción desatada por un actor externo. 

El evento del sistema es tratado o respondido por una operación del sistema. La relación es la misma que entre mensaje y método: el mensaje desencadena la acción del método; dicho de otro modo, el mensaje invoca al método.

Solución: asignar la responsabilidad de recibir o manejar un mensaje evento de entrada del sistema a una clase que representa alguna de estas opciones:

• controlador de fachada: representa al sistema global, dispositivo o subsistema. • controlador de sesión o de caso de uso: representa un escenario de caso de uso en el que tiene 

lugar el evento de entrada del sistema. Se suele llamar a estas clases con el nombre del caso de uso adjunto a una de las palabras Manejador, Gestor, Coordinador, Sesion. 

Una sesión es una instancia de intercambio de mensajes con un actor. Las sesiones pueden tener duración variable, pero frecuentemente están vinculadas a un caso de uso. Otra característica de las sesiones es que suelen tener un inicio y un final, con operaciones propias del inicio y operaciones propias del final.

Se llama Controlador a un objeto responsable de recibir o manejar eventos del sistema. El Controlador dispone de uno o varios métodos para atender uno o varios eventos del sistema. El Controlador no pertenece a la interfaz de usuario; es algo así como un intermediario entre la interfaz de usuario y el núcleo de clases donde reside la lógica de la aplicación.

Las clases de manejo gráfico de la ventana en la interfaz de usuario no deberían tratar ningún evento del sistema, sólo recibirlos; su única función es mostrar o recibir las acciones del usuario e inmediatamente transferir la actuación relativa al evento hacia una clase controlador propia de la aplicación. Esto diferencia claramente dos capas de software: la interfaz de usuario y la capa de dominio de la aplicación.

Ejemplo. Supermercado. Una buena clase candidata a Controlador es la clase Sesión. Esta clase puede responder a eventos del sistema mediante métodos tales como crearNuevaVenta(), ingresarArticulo(), recibirPago(), en los cuales no realiza las tareas por sí misma sino que crea o invoca métodos de otras clases, que son las que realizan efectivamente el trabajo.

Discusión. El Controlador no realiza mucho trabajo por sí mismo; más bien coordina la actividad de otros objetos. Recibe los eventos del sistema, pero no los trata, los deriva hacia otros objetos.

Un controlador de fachada representa al sistema completo, posiblemente con el nombre del sistema, dispositivo o subsistema que se está construyendo. Son útiles cuando no hay muchos eventos del sistema, o como inicio para invocar controladores de casos de uso.

Cuando se emplea un controlador de caso de uso, existe un controlador para cada caso de uso, o para cada escenario de caso de uso. Un controlador de caso de uso no es un objeto del dominio, sino una construcción artificial para atender los eventos del sistema propios de un cierto caso de uso o una instancia de caso de uso.

Beneficios:• aumenta la posibilidad de reuso de la lógica de la aplicación, que permanece independiente 

de la interfaz de usuario.• aumenta la posibilidad de emplear interfaces de usuario enchufables ("plugins"), cambiando 

la interfaz de usuario sin tocar la lógica de la aplicación.• asegura la secuencia correcta de operaciones cuando es necesario. En muchas oportunidades 

no es posible continuar si no se van cumpliendo diferentes condiciones, o es preciso cambiar el curso de operación según el resultado de operaciones previas. Esta traza de operaciones 

7 de 9

realizadas y condiciones cumplidas debe conocerla y manejarla alguien; el Controlador es el candidato preferido.

Contraindicaciones: no crear un Controlador porque sí, deben darse condiciones que lo requieran.

Un controlador mal diseñado tendrá baja cohesión, asume demasiadas responsabilidades o está muy diversificado, es un controlador saturado. No es imprescindible que haya un único Controlador, pueden crearse los necesarios para contemplar los principios de buen diseño.

Uso de un controlador GestorSistema para iniciar una sesión en un sistema: muestra una pantalla de bienvenida (IFPortada), valida al usuario, determina si es administrador y despliega el menú correspondiente (IFMenuUsuario o IFMenuAdmin). GestorUsuarios es otro controlador para funcionalidades relativas a los usuarios.

Realización de los casos de uso.

La realización de un caso de uso describe cómo se construye el caso de uso en el modelo de diseño, en términos de los objetos intervinientes y sus relaciones. Recordemos la secuencia de trabajo con los artefactos UML:

• el estudio del caso de uso permite descubrir los eventos del sistema; estos se muestran explícitamente en el diagrama de secuencia del sistema. 

• si se considera necesario, puede describirse el tratamiento de los eventos del sistema mediante el contrato de operación, donde se detallan los cambios de estado producidos por el evento en cuestión (precondiciones y postcondiciones). 

• los eventos del sistema representan los mensajes que inician los diagramas de interacción; se construye un diagrama de interacción por cada evento del sistema, en el cual se detalla todo el intercambio de mensajes entre objetos necesario para cumplir la tarea requerida; estos 

8 de 9

diagramas de interacción son la realización de los casos de uso, muestran la forma como se da cumplimiento a los requerimientos implícitos en el caso de uso. 

• los objetos descritos en los diagramas de interacción se inspiran en los nombres de las clases conceptuales halladas en el modelo del dominio, pero durante el trabajo de diseño es preciso incorporar nuevas clases conceptuales (clases de análisis) y también clases de diseño (clases de software) ajenas por completo al modelo de dominio, necesarias para el diseño.

• los patrones de diseño constituyen guías para la asignación de responsabilidades a las clases existentes, y también para decidir la creación de nuevas clases, tanto conceptuales como de diseño.

Referencias y lecturas recomendadas.

El contenido de este documento está basado en las fuentes citadas a continuación, cuya lectura o consulta no pretenden sustituir.

Lecturas recomendadas.

• [Larman2003] Larman, Craig. UML y patrones. Una introducción al análisis y diseño orientado a objetos y al Proceso Unificado, 2a. edición. Madrid, 2003.ISBN 84­205­3438­2.

• [Fowler1997] Fowler, Martin y Scott, Kendall. UML distilled. Applying the Standard Object Modelling Language. Addison Wesley Longman, Inc., 1997. ISBN 0­201­32563­2.

• [Pfleeger2002] PFLEEGER, SHARI LAWRENCE. Ingeniería de software, teoría y práctica, 1a. edición. Buenos Aires, Pearson educación, 2002. ISBN: 987­9460­71­5.

Referencias.

• [Jacobson2000] Jacobson, Ivar; Booch, Grady; Rumbaugh, James. El proceso unificado de desarrollo de software. Pearson Educación, Madrid, 2000. ISBN: 84­7829­036­2.

• [Booch1999] Booch, Grady; Jacobson, Ivar; Rumbaugh, James. El lenguaje unificado de modelado. Pearson Educación, Madrid, 2000. ISBN: 84­7829­028­1.

Errores, omisiones, comentarios: Víctor González Barbone, vagonbar en fing.edu.uy

Desarrollo de Software para Ingeniería Eléctrica ­ Rev. 2009­05­12Instituto de Ingeniería Eléctrica    ­    Facultad de Ingeniería    ­ Universidad de la República, Uruguay.   

9 de 9