Descripcion de los Patrones GRASP usados para el diseño orientado a objetos pare definir responsailidades y ayudara tener bienas practicas en el diseño de sistemas mediante UML

1. Ingeniería de Software
PATRONES GRASP
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.
«Cada patrón describe un problema que ocurre infinidad de veces
en nuestro entorno, así como la solución al mismo, de tal modo
que podemos utilizar esta solución un millón de veces más
adelante sin tener que volver a pensarla otra vez.«
Christopher Alexander
Arquitecto estadounidense (1979)

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. 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.

10. 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.

11. 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

12. PATRON EXPERTO
PROBLEMA: ¿Cuál es el principio fundamental en virtud del cual se asignan las
responsabilidades en el diseño orientado a objetos?
SOLUCIÓN: Asignar una responsabilidad al experto en información: la clase que cuenta
con la información necesaria para cumplir la responsabilidad.
EXPLICACIÓN: Experto es un patrón que se usa más que cualquier otro al asignar
responsabilidades; es un principio básico que suele utilizarse en el diseño orientado a
objetos. Da origen a diseños donde el objeto de software realiza las operaciones que
normalmente se aplican a la cosa real que representa, por lo que ofrece una analogía
con el mundo real.
BENEFICIOS: Con la utilización de este patrón se conserva el encapsulamiento, ya que
los objetos se valen de su propia información para hacer lo que se les pide. El
Comportamiento (de los objetos) se distribuye entre las clases que cuentan con la
información requerida, alentando con ello definiciones de clases sencillas y más
cohesivas que son más fáciles de comprender y mantener.

13. PATRON EXPERTO
EJEMPLO:
La responsabilidad de realizar una labor es de la clase que tiene o puede tener los datos
involucrados (atributos) . Una clase, contiene toda la información necesaria para realizar
la labor que tiene encomendada.
————
Hay que tener en cuenta que esto es aplicable mientras estemos considerando los
mismos aspectos del sistema:
• Lógica de negocio
• Persistencia a la base de datos
• Interfaz de usuario
————
No tiene sentido considerar que una clase se debe escribir a si misma en base de datos
o formatearse para presentarse en una página HTML por el hecho de poseer los datos.
Estos son elementos estructuralmente distintos y deben considerarse desde una
perspectiva distinta.

14. PATRON CREADOR(1)
PROBLEMA: ¿Quién debería ser responsable de crear una nueva instancia de alguna
clase?
SOLUCIÓN: Asignarle a la clase B la responsabilidad de crear una instancia de la clase
A en uno de los siguientes casos:
•B agrega los objetos A.
•B contiene los objetos A.
•B registra las instancias de los objetos A.
•B utiliza específicamente los objetos A.
•B tiene los datos de inicialización que serán trasmitidos a A cuando este objeto sea
creado (así que B es un Experto respecto a la creación de A).
•B es un creador de los objetos A.
•Si existe más de una opción, prefiera la clase B que agregue o contenga la clase A.

15. PATRON CREADOR(2)
EXPLICACIÓN:
El patrón Creador guía la asignación de responsabilidades relacionadas con la creación
de objetos. El propósito fundamental de este patrón es encontrar un creador que se debe
conectar con el objeto producido en cualquier evento.
BENEFICIOS:
Brinda un soporte a un bajo acoplamiento –patrón que será descrito más adelante– lo
que supone menos dependencias respecto al mantenimiento y mejores oportunidades
de reutilización.

16. PATRON BAJO ACOPLAMIENTO(1)
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.

17. PATRON BAJO ACOPLAMIENTO(2)
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.

18. PATRON BAJO ACOPLAMIENTO(3)
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)

19. PATRON ALTA COHESION(1)
PROBLEMA:
¿Cómo mantener la complejidad dentro de límites manejables? En la perspectiva del
diseño orientado a objetos, la cohesión es una medida de cuan relacionadas y
enfocadas están las responsabilidades de una clase. Una alta cohesión caracteriza a las
clases con responsabilidades estrechamente relacionadas que no realicen un trabajo
enorme. Una clase con baja cohesión hace muchas cosas no afines o un trabajo
excesivo. No conviene este tipo de clases pues presentan los siguientes problemas:
•Son difíciles de comprender.
•Son difíciles de reutilizar.
•Son difíciles de conservar.
•Son delicadas: las afectan constantemente los cambios.
Las clases con baja cohesión a menudo representan un alto grado de abstracción o han
asumido responsabilidades que deberían haber delegado a otros objetos.
SOLUCIÓN:
Asignar una responsabilidad de modo que la cohesión siga siendo alta.

20. PATRON ALTA COHESION(2)
EXPLICACIÓN:
El patrón Alta Cohesión es la meta principal que ha de tenerse en cuenta en cada
momento en todas las decisiones de diseño. Es un patrón evaluativo que el desarrollador
aplica al valorar sus decisiones de diseño. Una clase de alta cohesión posee un número
relativamente pequeño, con una importante funcionalidad relacionada y poco trabajo que
hacer. Colabora con otros objetos para compartir el esfuerzo si la tarea es grande.
BENEFICIOS:
Con el uso de este patrón mejoran la claridad y la facilidad con que se entiende el
diseño. Se simplifican el mantenimiento y las mejoras en funcionalidad. A menudo se
genera un bajo acoplamiento. La ventaja de una gran funcionalidad soporta una mayor
capacidad de reutilización, porque una clase muy cohesiva puede destinarse a un
propósito muy específico.

21. PATRON ALTA COHESION(3)
EJEMPLOS:
Ejemplos de una baja cohesión son clases que hacen demasiadas cosas.
—————-
En todas las metodologías se considera la refactorización. Uno de los elemento a
refactorizar son las clases saturadas de métodos.
—————-
Ejemplos de buen diseño se producen cuando se crean los denominados “paquetes de
servicio” o clases agrupadas por funcionalidades que son fácilmente reutilizables (bien
por uso directo o por herencia).
—————-
En java, pensar en interfaces nos fuerza a que nuestros sistemas sigan los principios de
alta cohesión. P.ej. una aplicación con menos de 8 interfaces no utiliza correctamente los
conceptos de orientación a objetos.

22. PATRON CONTROLADOR (1)
PROBLEMA:
¿Quién debería encargarse de atender un evento del sistema? Un evento del sistema es
un evento de alto nivel generado por un actor externo; es un evento de entrada externa.
Se asocia a operaciones del sistema: las que emite en respuesta a los eventos del
sistema. Un CONTROLADOR es un objeto de interfaz no destinada al usuario que se
encarga de manejar un evento del sistema. Define además el método de su operación.
SOLUCIÓN:
Asignar la responsabilidad del manejo de un mensaje de los eventos de un sistema a
una clase que represente una de las siguientes opciones:
• El “sistema” global (controlador de fachada).
• La empresa u organización global (controlador de fachada).
• Algo en el mundo real que es activo (por ejemplo, el papel de una persona) y
que pueda participar en la tarea (controlador de tareas).
• Un manejador artificial de todos los eventos del sistema de un caso de uso
(controlador de casos de uso).
NOTA: Utilice la misma clase de controlador con todos los eventos del sistema en el
mismo caso de uso.

23. PATRON CONTROLADOR(2)
EXPLICACIÓN:
La mayor parte de los Sistemas reciben eventos de entrada externa, los cuales
generalmente incluyen una interfaz gráfica para el usuario operado por una persona.
Otros medios de entrada son los mensajes externos o las señales procedentes de
sensores como sucede en los sistemas de control de procesos. En todos los casos, si se
recurre a un diseño orientado a objetos, hay que elegir los controladores que manejen
esos eventos de entrada. Este patrón ofrece una guía para tomar decisiones apropiadas
que generalmente se aceptan. La misma clase controlador debería utilizarse con todos
los eventos sistémicos de un caso de uso, de modo que se pueda conservar la
información referente al estado del caso.
BENEFICIOS:
Garantiza que la empresa o los procesos de dominio sean manejados por la capa de los
objetos del dominio y no por la de la interfaz. Al delegar a un controlador la
responsabilidad de la operación de un sistema entre las clases del dominio favorece la
reutilización de la lógica para manejar los procesos afines del negocio en aplicaciones
futuras.

24. 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 Asignacion 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/

25. GRACIAS POR SU ATENCION
Presento:
Fernando Alfonso Casas De la Torre
Matricula M1713019
fernando_casas69@hotmail.com
fernando.casas@imss.gob.mx