1. Ingeniería de Software
PATRON GRASP
DE BAJO ACOPLAMIENTO
Catedrática:
Dra. Elisa Urquizo Barraza
Presenta:
Fernando Alfonso Casas De la Torre
Matricula M1713019
Instituto Tecnológico de La Laguna
Maestría en Sistemas Computacionales
2. INTRODUCCION
PATRONES
Los PATRONES son una descripción de un problema y su solución que recibe
un nombre y que puede aplicarse en nuevos contextos. Los patrones tienen
nombres sugerentes que ayudan a identificarlos y facilitan la comunicación.
Una adecuada asignación de responsabilidades entre objetos contribuye al
desarrollo de sistemas .
3. INTRODUCCION
PATRONES
Un patrón es una descripción de un problema bien conocido, o sea de un
problema cuyas características son similares a otro el cual ya ha sido
solucionado de algún modo y que suele incluir:
• Descripción
• Escenario de Uso
• Solución concreta
• La consecuencias de utilizar este patrón (ventajas y desventajas)
• Ejemplos de implementación (analogías o similitudes)
• Lista de patrones relacionados
4. CARACTERISTICAS
PATRONES
Un patrón de diseño resulta ser una solución a un problema de diseño. Para
que una solución sea considerada un patrón debe poseer ciertas
características.
Características de los Patrones:
•EFECTIVIDAD: Se debe haber comprobado esto resolviendo problemas
similares en ocasiones anteriores.
•REUTILIZABLE: Es aplicable a diferentes problemas de diseño en distintas
circunstancias.
5. OBJETIVOS
Objetivos de los Patrones
Los patrones de diseño pretenden:
•Proporcionar catálogos de elementos reusables en el diseño de sistemas
software.
•Evitar la reiteración en la búsqueda de soluciones a problemas ya conocidos y
solucionados anteriormente.
•Formalizar un vocabulario común entre diseñadores.
•Estandarizar el modo en que se realiza el diseño.
•Facilitar el aprendizaje de las nuevas generaciones de diseñadores
condensando conocimiento ya existente.
Asimismo, no pretenden:
•Imponer ciertas alternativas de diseño frente a otras.
•Eliminar la creatividad inherente al proceso de diseño.
6. PATRON DE DISEÑO
PATRONES EN POO
En la Ingeniería de software al realizar la POO y el Diseño Orientado a Objetos
se busca desde el inicio tener un modo metódico de resolver los problemas por
lo que se buscan patrones a fin de identificar acciones a realizar en base a las
situaciones.
Los patrones de diseño son la base para la búsqueda de soluciones a
problemas comunes en el desarrollo de software y otros ámbitos referentes al
diseño de interacción o interfaces.
En resumen, los PATRONES son una descripción de un problema y su
solución que recibe un nombre y que puede aplicarse en nuevos contextos.
Los patrones tienen nombres sugerentes que ayudan a identificarlos y
facilitan la comunicación.
7. PATRONES GRASP
PATRONES GRASP
Por tal motivo se usan los GRASP que son Patrones Generales De Software
Para Asignación De Responsabilidades, que es el acrónimo de "GRASP
(Object-Oriented Design: General Responsibility Assignment Software
Patterns). Aunque se considera que más que patrones propiamente dichos,
son una serie de "buenas prácticas" de aplicación recomendable en el diseño
de software.
Los patrones GRASP describen los principios fundamentales de la asignación
de responsabilidades a objetos y sirven para asignar correctamente las
responsabilidades en el diseño de POO.
Los patrones GRASP son un método de enseñanza que ayuda a entender el
Diseño de POO y aplica el análisis y diseño de objetos de un modo
sistemático, racional y explicable.
8. PATRONES GRASP
Los patrones GRASP dependen de la información contenida para una situación
en:
•Modelo conceptual.
•Contratos de operación
•Casos de uso real(o esencial)
•Diagramas de colaboración.
Al analizar un problema se parte de su declaración y anunciamiento por lo que
se usa la siguiente NOTACION que nos ayudara a determinar que patrón usar:
Nombre del Patrón: Experto
Solución: Asignar una responsabilidad a la clase que tiene la
información necesaria.
Problema que resuelve: ¿cuál es el principio fundamental en virtud
de lo cual asignaremos las responsabilidades a los objetos ?
Nombre del Patrón: Experto
Solución: Asignar una responsabilidad a la clase que tiene la
información necesaria.
Problema que resuelve: ¿cuál es el principio fundamental en virtud
de lo cual asignaremos las responsabilidades a los objetos ?
9. CONCEPTOS
No todos los patrones son aplicables a todos los casos pero si un tipo de
patrón o varios pueden ser usados para resolver alguna situación.
Veremos uno de los tipos de Patrón GRASP utilizados: el tipo de patrón de
BAJO ACOPLAMIENTO pero antes definamos algunos conceptos y como
tienen que ver con el diseño y funcionalidad de un sistema como son..
•CLASE
•RESPONSABILIDAD
•ACOPLAMIENTO
•COHESION
10. CLASES
Se tiene en las clases lo siguiente:
1. CLASES
2. TIPOS DE CLASES
3. RELACIONES ENTRE CLASES
4. RESPONSABILIDADES ENTRE CLASES
Todo problema de análisis de diseño en POO debe de seccionarse en:
PROBLEMA
CLASE RESPONSABILIDAD
11. RESPONSABILIDADES
Al implementar una CLASE se debe de establecer su responsabilidad y esto
implica dos cosas:
¿Cómo asignar responsabilidades? Asignar una responsabilidad al objeto que
tiene la información necesaria para realizarla: “El objeto que tiene la
información realiza el trabajo”. Por ejemplo:
• ¿Qué objeto de software calcula el impuesto sobre las ventas?
• ¿Qué tipo de información se necesita para llevar a cabo esta tarea?
• ¿Qué objeto u objetos tienen la mayor parte de esta información?
CONOCER HACER
La clase debe estar enterada de
como son sus datos encapsulados.
Hacer algo por si misma
Estar enterado de la existencia de
objetos conexos
Iniciar una acción en o hacia otros
objetos
Estar enterado de cosas que se
deben calcular o derivar
Controlar o coordinar acciones en o
a otros objetos
12. RESPONSABILIDADES
Las clases en base a su tipo de responsabilidad o acción define también el tipo
de patrón de responsabilidad.
En base al tipo de responsabilidad será el patrón de asignación de
responsabilidades o patrones GRASP los cuales definirán el diseño como se
menciono antes son de diversos tipos como tipo Experto, Creador, Alta
Cohesión, Bajo Acoplamiento, Controlador, etc.
.
Se tienen por lo tanto que al implementar una CLASE se debe de establecer su
responsabilidad
13. COHESION y ACOPLAMIENTO
El acoplamiento y la cohesión juegan un rol central en el diseño de software el
cual tiene como objetivo minimizar los costos. El costo del software está
determinado por el costo de mantenimiento, y el costo del mantenimiento está
determinado por el costo de los cambios que surgen en el sistema.
Un diseño de software efectivo minimiza la probabilidad de que se propaguen
los cambios. Los cambios que involucran a un único elemento son menos
costosos y más predecibles que los cambios a un elemento que requieren
cambiar dos más, y luego tres...
El costo esperado del cambio se puede reducir prestando especial atención a
dos factores: el acoplamiento entre los elementos y la cohesión dentro de los
elementos. El diseño de software también es importante para incrementar o
acelerar las ganancias, pero las ganancias no están directamente conectadas
al acoplamiento y la cohesión.
14. ACOPLAMIENTO
ACOPLAMIENTO
Dos elementos están acoplados en la medida en el que los cambios en uno
tienden a necesitar cambios en el otro. Por ejemplo, la comunicación por red
entre dos sistemas está acoplada respecto a cambios en el protocolo - si un
sistema necesita ambirar el protocolo, el otro va a necesitar cambiar también.
El acoplamiento entre los elementos es un conductor de cambios.
El acoplamiento mide la dispersión del cambio a través de los elementos.
15. COHESION
La cohesión mide el costo del cambio dentro de un elemento. Un elemento es
cohesivo a medida que cambia el elemento entero cuando el sistema necesita
cambiar.
Un elemento puede tener poca cohesión tanto por ser muy grande o muy
pequeño. Un elemento muy pequeño, que resuelve sólo una parte del
problema, va a necesitar estar acoplado a otros elementos para resolver las
otras partes del problema. Si cambia la solución se va a necesitar cambiar
todos los elementos. Un elemento que resuelve muchos problemas sólo va a
necesitar cambiarse en parte.
16. BALANCE
Una aplicación debe de tener un buen diseño por lo que la COHESION y el
ACOPLAMIENTO deben estar balanceados. Se puede resolver un problema y
tener un mal o buen diseño pero se debe optar por una buena solución y un
buen diseño.
17. BALANCE
En resumen un buen diseño es inversamente proporcional a su acoplamiento y
directamente proporcional a su cohesión.
18. PATRONES GRASP
Se debe asignar al diagrama de colaboración las responsabilidades de los
objetos, para ello se sabe que en el contexto donde se deben considerar estas
responsabilidades siempre es durante la creación de estos diagramas. Los
objetos y sus responsabilidades pueden dibujarse para una mejor comprensión
y análisis.
Se deben asignar o ver las responsabilidades de las partes involucradas. Por
ejemplo:
•La clase que tiene la información necesaria para satisfacer la responsabilidad.
•Cada objeto es responsable por mantener su propia información o principio de
encapsulamiento
– Conoce y puede informar el valor de sus atributos
– Puede modificar el valor de sus atributos.
19. PATRONES GRASP
Para hacerlo se usa el conjunto de patrones de asignación de
responsabilidades de los objetos o patrones GRASP, estos constituyen un
apoyo para la enseñanza y el entendimiento del diseño de objetos.
Las responsabilidades se relacionan con las obligaciones de un objeto
respecto a su comportamiento.
Significa que los objetos
VENTA tienen la
responsabilidad de
IMPRIMIR
:Venta
Imprimir()
20. PATRONES GRASP
Los Patrones GARSP establecen principios de diseño para la elaboración de
objetos y en un sistema orientado a objetos se encuentra que se compone de
objetos que envían mensajes a otros objetos para que lleven a cabo las
operaciones requeridas. Los diagramas de interacción describen gráficamente
estas operaciones, a partir de los objetos en interacción, que se
responsabilizan de una actividad determinada.
Se clasifican en los siguientes tipos de patrones:
Experto
Creador
Alta Cohesión
Bajo Acoplamiento
Controlador
21. PATRON BAJO ACOPLAMIENTO
El patrón Bajo Acoplamiento es un principio a tener en mente en todas las
decisiones de diseño; es un objetivo a tener en cuenta continuamente.
Es un principio evaluativo que aplica un diseñador mientras evalúa todas las
decisiones de diseño.
El patrón impulsa la asignación de responsabilidades de manera que su
localización no incremente el acoplamiento hasta un nivel que lleve a los
resultados negativos que puede producir un acoplamiento alto.
No puede considerarse en forma independiente de otros patrones como
Experto o Alta Cohesión, sino que más bien ha de incluirse como uno de los
principios del diseño que influyen en la decisión de asignar responsabilidades
22. PATRON BAJO ACOPLAMIENTO
PROBLEMA:
¿Cómo dar soporte a una dependencia escasa y aun aumento de la reutilización? El
acoplamiento es una medida de la fuerza con que una clase está conectada a otras
clases, con que las conoce y con que recurre a ellas. Una clase con bajo (o débil)
acoplamiento no depende de muchas otras clases. Una clase con alto (o fuerte)
acoplamiento recurre a muchas otras. Este tipo de clases no es conveniente, ya que
presentan los siguientes problemas:
•Los cambios de las clases afines ocasionan cambios locales
•Son más difíciles de entender cuando están aisladas.
•Son más difíciles de reutilizar porque se requiere la presencia de otras clases de las que
dependen.
SOLUCIÓN:
Asignar una responsabilidad para mantener bajo acoplamiento.
23. PATRON BAJO ACOPLAMIENTO
ACOPLAMIENTO.
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 tiene las siguientes desventajas:
•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’)
1) Problema: ¿Cómo evitar estos inconvenientes?
2) Solución : Asigne responsabilidades de manera que el acoplamiento
permanezca en un nivel bajo
•¿Es una solución?
•Principio evaluativo: lo aplica un diseñador cada vez que tiene que evaluar
una decisión de diseño
24. PATRON BAJO ACOPLAMIENTO
EXPLICACIÓN:
El bajo acoplamiento es un principio que se debe tener siempre en cuenta durante las
decisiones de diseño. Es un patrón evaluativo que el diseñador aplica al juzgar sus
decisiones de diseño. Este patrón estimula asignar una responsabilidad de modo que su
colocación no incremente el acoplamiento tanto que produzca los resultados negativos
propios de un alto acoplamiento. Soporta el diseño de clases más independientes, que
reducen el impacto de los cambios, y también más reutilizables, que acrecienten la
oportunidad de una mayor productividad. No puede considerarse en forma independiente
de otros patrones como Experto o Alta cohesión, sino que más bien ha de incluirse como
uno de los principios del diseño que influyen en la decisión de asignar responsabilidades.
BENEFICIOS:
Con el uso de este patrón los componentes no se afectan por cambios de otros
componentes, son fáciles de entender por separado y fáciles de reutilizar.
25. PATRON BAJO ACOPLAMIENTO
EJEMPLOS:
Debe haber pocas dependencias entre las clases. Si todas las clases dependen de todas
¿cuanto software podemos extraer de un modo independiente y reutilizarlo en otro
proyecto?. Para determinar el nivel de acoplamiento de clases, son muy buenos los
diagramas de colaboración de UML.
————–
Uno de los principales síntomas de un mal diseño y alto acoplamiento es una herencia
muy profunda. Siempre hay que considerar las ventajas de la delegación respecto de la
herencia.
————–
Como ejemplo (de mal diseño), en muchos diseños Web se puede ver como se crea un
servlet base con capacidades de paginación y se hereda de él para construir los demás.
La paginación es un servicio que se podría usar en aplicaciones no Web, por lo que es
más adecuado mantener estas capacidades en clases externas.
————–
Otro ejemplo clásico se produce cuando se pasan los objetos relacionados con la capa
de presentación a la capa de negocio (HttpRequest, HttpResponse)
26. PATRON BAJO ACOPLAMIENTO
EJEMPLOS:
Debe haber pocas dependencias entre las clases. Si todas las clases dependen de todas
¿cuanto software podemos extraer de un modo independiente y reutilizarlo en otro
proyecto?. Para determinar el nivel de acoplamiento de clases, son muy buenos los
diagramas de colaboración de UML.
————–
Uno de los principales síntomas de un mal diseño y alto acoplamiento es una herencia
muy profunda. Siempre hay que considerar las ventajas de la delegación respecto de la
herencia.
————–
Como ejemplo (de mal diseño), en muchos diseños Web se puede ver como se crea un
servlet base con capacidades de paginación y se hereda de él para construir los demás.
La paginación es un servicio que se podría usar en aplicaciones no Web, por lo que es
más adecuado mantener estas capacidades en clases externas.
————–
Otro ejemplo clásico se produce cuando se pasan los objetos relacionados con la capa
de presentación a la capa de negocio (HttpRequest, HttpResponse)
27. PATRON BAJO ACOPLAMIENTO
EJEMPLO:
Considere el caso de un programa de Punto de Venta en el que se presentan las
siguientes clases…
Pago VentasRegistro
Asumimos que se tiene la necesidad de crear una instancia llamada PAGO que se
asociara con una instancia llamada VENTAS ¿Qué clase debería de ser la responsable
de esto? Entonces se tiene …
Problema:¿Qué clase debería ser responsable de crear una instancia de Pago y
asociarla con una instancia de Ventas ?
28. PATRON BAJO ACOPLAMIENTO
Puesto que un REGISTRO «registra» a un pago en el mundo real, el patrón de tipo
CREADOR sugiere que se use a REGISTRO como clase candidata para la creación de
la clase PAGO.. La instancia de REGISTRO podrá entonces enviar el mensaje
addPAGO a la VENTA pasando el nuevo PAGO como parámetro.
Ventas
Registro
Pago Cliente
Capturado para
Es paraPagado por
0..1
1 1
11 1
29. PATRON BAJO ACOPLAMIENTO
Puesto que Registro registra el pago en el dominio del mundo real, el GRASP Creador
sugiere lo siguiente...
:Ventas
:Registro :Pago
1: Crear ()
2: addPago ()
Hacer pago()
Solución: Puesto que Registro esta acoplado con Pago y Ventas podríamos disminuir el
acoplamiento registra el pago (Pago) en el dominio del mundo real, el GRASP Creador
sugiere lo siguiente...
:Ventas:Registro
:Pago
1:HacerPago ()
1.1: Crear()
Hacer pago ()
La VENTA crea al PAGO
El REGISTRO crea un PAGO
30. REFERENCIAS
• UML y Patrones 2da edición. Craig Larman
• Análisis De Diseño y Patrones De Diseño. Varios autores (Claros Loayza Melicia,
Loayza Villarroel Luz, Mamani Santos Nadir, Pocoata Condori Maura)
• WIKIPEDIA
https://es.wikipedia.org/wiki/GRASP
https://es.wikipedia.org/wiki/Patr%C3%B3n_de_dise%C3%B1o
• Patrones de Asignación de Responsabilidades
https://www.ecured.cu/Patrones_de_Asignaci%C3%B3n_de_Responsabilidades
• Patrones en UML. Blog «Adictos al trabajo»
https://www.adictosaltrabajo.com/tutoriales/grasp/
•Patrones de Asignación de Responsabilidades. Sitio web de Universidad de Sevilla
http://www.lsi.us.es/docencia/get.php?id=906
Introducción al Acoplamiento y la Cohesión
https://www.youtube.com/watch?v=sOAFiBrIkZ8
31. GRACIAS POR SU ATENCION
Presento:
Fernando Alfonso Casas De la Torre
Matricula M1713019
fernando_casas69@hotmail.com
fernando.casas@imss.gob.mx