FACULTAD DE INGENIERÍA Y ARQUITECTURA

ESCUELA PROFESIONAL DE ING. DE SISTEMAS

TITULO DE INVESTIGACIÓN

GRASP 2

AUTOR(ES):

Atuncar Meneses, Bryan Alexander

Bustinza Castillo, José David
Chala Echevarria, Carlos Piero
Cosio Martínez, Christopher Israel

DOCENTE:

ING. JOSUE JOEL RIOS HERRERA

LIMA – Perú
INDICE

BAJO ACOPLAMIENTO

- Problema
- Solución
- Discusión
- Contradicciones
- Beneficios
- Antecedentes
- Patrones Relacionados

ALTA COHESIÓN

- Problema
- Solución
- Cohesión Funcional
- Discusión
- Contradicciones
- Beneficios
- Patrones relacionados

CONTROLADOR

- Problema
- Solución
- Controlador de Fachada
- Ventajas
- Beneficios

ANEXOS

REFERENCIAS BIBLIOGRÁFICAS

LIMA – Perú
Bajo Acoplamiento

Es la idea de tener las clases lo menos ligadas entre sí que se pueda. De tal forma que, en caso
de producirse una modificación en alguna de ellas, se tenga la mínima repercusión posible en
el resto de clases, potenciando la reutilización, y disminuyendo la dependencia entre las clases.

Es una medida de la fuerza con que un elemento está conectado a, tiene conocimiento de,
confía en, otros elementos.

Un elemento fuertemente acoplado

 Se resiente de los cambios en los elementos relacionados.

 Son difíciles de entender de manera aislada.
 Difíciles de reutilizar (requiere las clases “acopladas”).

Problema: ¿Cómo evitar estos inconvenientes?

Solución: Asigne responsabilidades de manera que el acoplamiento permanezca bajo.
 ¿Es una solución?
 Principio evaluativo: lo aplica un diseñador cada vez que tiene que evaluar una
decisión de diseño.

Ejemplo:

¿Qué clase debería ser responsable de crear una instancia de Payment y asociarla con una
instancia de Sale?

 Puesto que Register registra el pago (Payment) en el dominio del mundo real, el
GRASP Creador sugiere…

LIMA – Perú
  Register está acoplado con Payment y con Sale. Sale también está acoplado con
Payment.
 ¿Cómo podríamos reducir el acoplamiento?

Discusión:
 En la práctica, el nivel de acoplamiento no puede evaluarse sin tener en cuenta otros GRASP
como la cohesión o el experto.
 Una subclase está fuertemente acoplada a su superclase. Esta decisión deber ser estudiada
cuidadosamente
 ¿Qué inconvenientes encuentra en hacer que todas las clases que requieren persistencia
deriven de una superclase PersistentObject?
 ¿Se resiente de los cambios en los elementos relacionados?
 ¿Es difícil de entender de manera aislada?
 ¿Requiere de las clases acopladas para poder ser reutilizadas?
 No existe medida que indique si el acoplamiento es demasiado alto → lo que debe tener en
cuenta el diseñador es el impacto que provoca una decisión en el grado de acoplamiento.
 ¿Qué ocurriría si intentáramos reducir el máximo el acoplamiento?
 …Antipatrón BLOB.
Contradicciones:

 Escoger las batallas

 El alto acoplamiento no es inherente malo, lo es sólo con elementos “inestables” (en su
contrato sintáctico, semántico, o su simple presencia).
- Una aplicación J2EE puede acoplarse con seguridad con la biblioteca [Link].*
 No se debe invertir esfuerzos en reducir el acoplamiento cuando no hay motivos reales
para hacerlo (Generalizitis)
- Si se preveen diferentes métodos de pago puede merecer la pena desacoplar Register
de Payment y utilizar el PD Strategy para los diferentes pagos.

LIMA – Perú
 Beneficios:

Se amortigua el impacto de los cambios en los elementos instables.

Se facilita el entendimiento.
Facilita la reutilización.

Antecedentes:

Acoplamiento y cohesión son principios realmente fundamentales que fueron propuestos por Larry
Constantine a finales de los 60 (40 años…)

Patrones relacionados:

Alta Cohesión.

Alta Cohesión

Cohesión (funcional). Es una medida de la fuerza con la que se relacionan y del grado de focalización de
las responsabilidades de un elemento.
Un elemento con baja cohesión tiene muchas responsabilidades:
 Difíciles de entender, reutilizar y mantener.
 Delicadas, frágiles (muchas probabilidades de verse afectada en los cambios).
Problema: ¿Cómo mantener manejable la complejidad?
Solución: Asigne responsabilidades de manera que la cohesión permanezca alta.
 ¿Es una solución?
 También es un principio evaluativo.

Ejemplo:
¿Qué clase debería ser responsable de crear una instancia de Payment y asociarla con una instancia de
Sale?

 Puesto que Register registra el pago (CashPayment) en el dominio del

mundo real, el GRASP Creador sugiere…

LIMA – Perú
 ¿Qué pasaría si Register siguiera haciéndose responsable de las
operaciones de sistema?
 Iría perdiendo cohesión progresivamente.
 ¿Cómo se podría conseguir una mejor cohesión?

Discusión:
 No es fácil cuantificar el grado de cohesión de un elemento. Para G. Booch, un elemento es
altamente cohesivo si:
 Todos sus elementos trabajan juntos para proporcionar algún comportamiento bien
delimitado.
 Escenarios que ilustran diferentes grados de cohesión funcional.
 Muy baja cohesión. Una clase responsable de muchas cosas en áreas funcionales diferentes
(Clase InterfazBDR-RPC).
 Baja cohesión. Una clase responsable de una tarea compleja de un área funcional (Clase
InterfazBDR). (No es el caso de la fachada JDBC).
 Alta cohesión. Una clase con responsabilidad “moderada” en un área funcional que
colabora con otras para llevar a cabo las tareas (La fachada de JDBC).
 Moderada cohesión. Una clase tiene responsabilidades “ligeras” y únicas en unas pocas
áreas diferentes que están lógicamente relacionados con el concepto de la clase, pero la
relación entre ellas no es fuerte.
 Una clase altamente cohesiva suele:
 Tener un número relativamente pequeño de métodos, con funcionalidad altamente
relacionada.
 No realiza mucho trabajo.
 Colabora con otras clases para compartir el esfuerzo.
 Una de las posibles analogías en el mundo real.
 Un trabajador con muchas responsabilidades (que no mucha responsabilidad) suele ser poco
efectivo.
 Diseño modular.
 Cohesión y acoplamiento son principios conocidos desde hace mucho. A partir de ellos se define
el principio de modularidad.
 Un diseño es modular si se descompone en un conjunto de módulos cohesivos y débilmente
acoplados.
 Cohesión y acoplamiento: el ying y el yang de la IS.

LIMA – Perú
  Una mala cohesión causa, normalmente, un mal acoplamiento.
 La filosofía china los considera como fuerzas opuestas pero complementarias.
 Un buen diseño siempre logra un buen equilibrio entre cohesión y acoplamiento.
Contradicciones:
 Existen pocas situaciones que justifiquen la aceptación de una baja cohesión (Fachadas).
Beneficios:
 Se incrementa claridad y comprensión.
 Se simplifica el mantenimiento.
 Favorece el bajo acoplamiento.
 Facilita la reutilización.
Patrones relacionados:
 Bajo acoplamiento.

Controlador

El patrón controlador es un patrón que sirve como intermediario entre una determinada interfaz y el algoritmo
que la implementa, de tal forma que es la que recibe los datos del usuario y la que los envía a las distintas clases
según el método llamado.

Este patrón sugiere que la lógica de negocios debe estar separada de la capa de presentación, esto para aumentar
la reutilización de código y a la vez tener un mayor control.

Se recomienda dividir los eventos del sistema en el mayor número de controladores para poder aumentar la
cohesión y disminuir el acoplamiento.

Asignar la responsabilidad de controlar el flujo de eventos del sistema, a clases específicas. Esto facilita la
centralización de actividades (validaciones, seguridad, etc.). El controlador no realiza estas actividades, las
delega en otras clases con las que mantiene un modelo de alta cohesión.

Un error muy común es asignarle demasiada responsabilidad y alto nivel de acoplamiento con el
resto de los componentes del sistema.

En UP (proceso unificado), al construir el modelo de análisis, existen estereotipos predefinidos que

favorecen la separación de entidades, mecanismos de interfaz y mecanismos de control.

En aplicaciones Web, se tiende a separación de la lógica de presentación y de la lógica de negocio.

Patrones bien conocidos como MVC o Fachada, son de amplia utilización.

Hay otros muchos patrones relacionados sobre todo en entornos multi-capa (Core J2EE patterns).

LIMA – Perú
 En el diseño de clases de negocio, cuando no tenemos claro a qué clase pertenece la responsabilidad de
realizar una determinada tarea, crear una clase controlador que se llame igual a la tarea a desempeñar.

Problema: ¿Quién es el responsable de manejar los eventos de entrada externos del sistema?

Solución: Asignar la responsabilidad de manejar los mensajes, eventos del sistema a una clase que
representa una de las siguientes elecciones:

 El sistema total, La empresa u organización (controlador de fachada).

 Algo en el mundo real que está activo ([Link]. El rol de una persona) y que puede participar en la
tarea (controlador de tareas).
 Un manejador artificial de los eventos del sistema relacionados con un caso de uso.
(sessioncontroller).
 Un evento de entrada al sistema es algún evento desde algún actor externo (humano ó no)
 El objeto controlador es responsable de decidir qué hacer con el evento
 El controlador se aplica para el manejo de interfaces externas y al manejo de entradas desde
interfaces de usuario.
 Los controladores de interface de usuario generalmente tienen la forma: <nombre caso de
uso> Coordinador, Manejador, Sesión.
 El controlador actúa como una fachada entre la interface y la aplicación.
 Los controladores delegan el trabajo a otros objetos ellos no hacen nada por sí mismos.

Controlador de Fachada:
 El controlador de fachada oculta un sistema debajo de una clase, como un Register o
un system.
 La fachada trabaja bien si tiene pocos eventos para manejar, de otra manera es
necesario tener varios de acuerdo a controladores por caso de uso.
 Pueden existir varias fachadas, esto para evitar que una sola clase controladora sea
muy grande.
 Los controladores podrían tener atributos.
 Las fachadas permiten mantener la separación del modelo de negocios y la vista (GUI),
la vista
 no debe interactuar directamente con el modelo, esto se conoce como la modelo vista
controlador (MVC).
 Permite mantener bajo acoplamiento entre Subsistemas.

Ventajas del Controlador de Fachada:

Algunas ventajas:
 Los cambios al modelo (dominio) no afectan el GUI (vista) y viceversa.

LIMA – Perú
  Provee una separación entre lógica de negocio y la visual.

 Pueden existir varias fachadas, esto para evitar que una sola clase controladora sea
muy grande.
 Los controladores podrían tener atributos.
 Las fachadas permiten mantener la separación del modelo de negocios y la vista (GUI),
la vista
 no debe interactuar directamente con el modelo, esto se conoce como la modelo vista
controlador (MVC).
 Permite mantener bajo acoplamiento entre Subsistemas.

Ventajas GRASP Controlador de Fachada:

 Los cambios al modelo (dominio) no afectan el GUI (vista) y viceversa.
 Proveen una separación entre la lógica de un negocio visual.

ANEXOS

LIMA – Perú
REFERENCIAS BIBLIOGRAFICAS
 Escuela Técnica Superior de Ingeniería Informática de la Universidad de Sevilla

& Grupo de Investigación de Ingeniería Web y Testing Temprano. (2012,

noviembre). SOLID y GRASP. Buenas prácticas hacia el éxito en el desarrollo de

LIMA – Perú
 software. [Link]

[Link]

 Mehta, A., Mittal, I., & Kakkar, A. (2022).

[Link] Acta Scientific Dental

Scienecs, 57–59. [Link]

 Departamento de Lenguajes y Sistemas Informáticos. (2010, agosto). Patrones

de asignación de responsabilidades (GRASP) (Tema 4). Escuela Técnica

Superior de Ingeniería Informática. [Link]

id=715

LIMA – Perú