SlideShare una empresa de Scribd logo
1 de 31
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
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 .
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
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.
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.
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.
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.
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 ?
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
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
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
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
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.
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.
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.
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.
BALANCE
En resumen un buen diseño es inversamente proporcional a su acoplamiento y
directamente proporcional a su cohesión.
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.
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()
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
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
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.
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
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.
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)
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)
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 ?
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
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
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
GRACIAS POR SU ATENCION
Presento:
Fernando Alfonso Casas De la Torre
Matricula M1713019
fernando_casas69@hotmail.com
fernando.casas@imss.gob.mx

Más contenido relacionado

La actualidad más candente

Principios orientacion-objetos
Principios orientacion-objetosPrincipios orientacion-objetos
Principios orientacion-objetoskarlalopezbello
 
Diagrama de clases
Diagrama de clasesDiagrama de clases
Diagrama de clasesjmachado614
 
Ejemplos de proyectos al modelo en cascada
Ejemplos de proyectos  al modelo en cascadaEjemplos de proyectos  al modelo en cascada
Ejemplos de proyectos al modelo en cascadaaics-1986-13-saraguro
 
Mapa mental uml
Mapa mental umlMapa mental uml
Mapa mental umlrigo berto
 
Estándar IEEE 830-1998 - Especificacón de requisitos de Software
Estándar IEEE 830-1998 - Especificacón de requisitos de SoftwareEstándar IEEE 830-1998 - Especificacón de requisitos de Software
Estándar IEEE 830-1998 - Especificacón de requisitos de SoftwareDaniel Guaycha
 
Patrones de diseño(presentación 7)
Patrones de diseño(presentación 7)Patrones de diseño(presentación 7)
Patrones de diseño(presentación 7)programadorjavablog
 
Modelo de desarrollo concurrente
Modelo de desarrollo concurrenteModelo de desarrollo concurrente
Modelo de desarrollo concurrentesamuel ospino
 
Herencia - Programación Orientada a Objetos
Herencia - Programación Orientada a ObjetosHerencia - Programación Orientada a Objetos
Herencia - Programación Orientada a ObjetosMario Villaseñor
 
Unidad 4 a HERENCIA, CLASES ABSTRACTAS, INTERFACES Y POLIMORFISMO . UML
Unidad 4 a HERENCIA, CLASES ABSTRACTAS, INTERFACES Y POLIMORFISMO . UMLUnidad 4 a HERENCIA, CLASES ABSTRACTAS, INTERFACES Y POLIMORFISMO . UML
Unidad 4 a HERENCIA, CLASES ABSTRACTAS, INTERFACES Y POLIMORFISMO . UMLCindy Adriana Bohórquez Santana
 
Diagramas estados
Diagramas estadosDiagramas estados
Diagramas estadosloco8888
 
Conceptos de POO (Programacion Orientada a Objetos)
Conceptos de POO (Programacion Orientada a Objetos)Conceptos de POO (Programacion Orientada a Objetos)
Conceptos de POO (Programacion Orientada a Objetos)Josue Lara Reyes
 
Estilos y Patrones Aplicables a la Arquitectura de Software
Estilos y Patrones Aplicables a la Arquitectura de SoftwareEstilos y Patrones Aplicables a la Arquitectura de Software
Estilos y Patrones Aplicables a la Arquitectura de SoftwareDiego Plascencia Lara
 

La actualidad más candente (20)

Modelo 4+1
Modelo 4+1Modelo 4+1
Modelo 4+1
 
Diseño de patrones
Diseño de patronesDiseño de patrones
Diseño de patrones
 
Arquitectura del software
Arquitectura del softwareArquitectura del software
Arquitectura del software
 
Principios orientacion-objetos
Principios orientacion-objetosPrincipios orientacion-objetos
Principios orientacion-objetos
 
Diagrama de clases
Diagrama de clasesDiagrama de clases
Diagrama de clases
 
Ejemplos de proyectos al modelo en cascada
Ejemplos de proyectos  al modelo en cascadaEjemplos de proyectos  al modelo en cascada
Ejemplos de proyectos al modelo en cascada
 
Mapa mental uml
Mapa mental umlMapa mental uml
Mapa mental uml
 
Modelamiento software
Modelamiento softwareModelamiento software
Modelamiento software
 
Patrones GRASP
Patrones GRASPPatrones GRASP
Patrones GRASP
 
Estándar IEEE 830-1998 - Especificacón de requisitos de Software
Estándar IEEE 830-1998 - Especificacón de requisitos de SoftwareEstándar IEEE 830-1998 - Especificacón de requisitos de Software
Estándar IEEE 830-1998 - Especificacón de requisitos de Software
 
Patrones de diseño(presentación 7)
Patrones de diseño(presentación 7)Patrones de diseño(presentación 7)
Patrones de diseño(presentación 7)
 
Modelo de desarrollo concurrente
Modelo de desarrollo concurrenteModelo de desarrollo concurrente
Modelo de desarrollo concurrente
 
Herencia - Programación Orientada a Objetos
Herencia - Programación Orientada a ObjetosHerencia - Programación Orientada a Objetos
Herencia - Programación Orientada a Objetos
 
Modelo 4+1
Modelo 4+1Modelo 4+1
Modelo 4+1
 
Unidad 4 a HERENCIA, CLASES ABSTRACTAS, INTERFACES Y POLIMORFISMO . UML
Unidad 4 a HERENCIA, CLASES ABSTRACTAS, INTERFACES Y POLIMORFISMO . UMLUnidad 4 a HERENCIA, CLASES ABSTRACTAS, INTERFACES Y POLIMORFISMO . UML
Unidad 4 a HERENCIA, CLASES ABSTRACTAS, INTERFACES Y POLIMORFISMO . UML
 
Diagramas estados
Diagramas estadosDiagramas estados
Diagramas estados
 
MVC
MVCMVC
MVC
 
Conceptos de POO (Programacion Orientada a Objetos)
Conceptos de POO (Programacion Orientada a Objetos)Conceptos de POO (Programacion Orientada a Objetos)
Conceptos de POO (Programacion Orientada a Objetos)
 
Estilos y Patrones Aplicables a la Arquitectura de Software
Estilos y Patrones Aplicables a la Arquitectura de SoftwareEstilos y Patrones Aplicables a la Arquitectura de Software
Estilos y Patrones Aplicables a la Arquitectura de Software
 
10.el diseño en el nivel de componentes
10.el diseño en el nivel de componentes10.el diseño en el nivel de componentes
10.el diseño en el nivel de componentes
 

Similar a Patrones GRASP de tipo de bajo acoplamiento

Uso de-patrones-de-arquitectura-capitulo-4
Uso de-patrones-de-arquitectura-capitulo-4Uso de-patrones-de-arquitectura-capitulo-4
Uso de-patrones-de-arquitectura-capitulo-4Ozzy Bull
 
Unidad 9 Patrones De DiseñO
Unidad 9 Patrones De DiseñOUnidad 9 Patrones De DiseñO
Unidad 9 Patrones De DiseñOSergio Sanchez
 
Diagramas de interaccion - Cun Monteria
Diagramas de interaccion - Cun MonteriaDiagramas de interaccion - Cun Monteria
Diagramas de interaccion - Cun MonteriaAndres Macea Tirado
 
1 3 ingenieria software y patrones de diseño
1 3 ingenieria software y patrones de diseño1 3 ingenieria software y patrones de diseño
1 3 ingenieria software y patrones de diseñolandeta_p
 
2.4 DISEÑO BASADO EN PATRONES.pptx
2.4 DISEÑO BASADO EN PATRONES.pptx2.4 DISEÑO BASADO EN PATRONES.pptx
2.4 DISEÑO BASADO EN PATRONES.pptxGonzaloMartinezSilve
 
12-150203140754-conversion-gate02.pptx
12-150203140754-conversion-gate02.pptx12-150203140754-conversion-gate02.pptx
12-150203140754-conversion-gate02.pptxGonzaloMartinezSilve
 
Metodologías para el Análisisy Diseño de Sistemas
Metodologías para el Análisisy Diseño de SistemasMetodologías para el Análisisy Diseño de Sistemas
Metodologías para el Análisisy Diseño de Sistemasalberto_marin11
 
Metodologías para el Análisisy Diseño de Sistemas
Metodologías para el Análisisy Diseño de SistemasMetodologías para el Análisisy Diseño de Sistemas
Metodologías para el Análisisy Diseño de Sistemasalberto_marin11
 
Analisis de sistemas
Analisis de sistemasAnalisis de sistemas
Analisis de sistemasjose2519
 
Slideshare 2do corte, luismortell
Slideshare 2do corte, luismortellSlideshare 2do corte, luismortell
Slideshare 2do corte, luismortellforwer1223
 
Analisis de requerimiento
Analisis de requerimientoAnalisis de requerimiento
Analisis de requerimientoturlahackers
 
Patrones de diseño I
Patrones de diseño IPatrones de diseño I
Patrones de diseño Ikaolong
 
Metodologías para el desarrollo de sistemas
Metodologías para el desarrollo de sistemasMetodologías para el desarrollo de sistemas
Metodologías para el desarrollo de sistemasmireya2022
 

Similar a Patrones GRASP de tipo de bajo acoplamiento (20)

Uso de-patrones-de-arquitectura-capitulo-4
Uso de-patrones-de-arquitectura-capitulo-4Uso de-patrones-de-arquitectura-capitulo-4
Uso de-patrones-de-arquitectura-capitulo-4
 
Unidad 9 Patrones De DiseñO
Unidad 9 Patrones De DiseñOUnidad 9 Patrones De DiseñO
Unidad 9 Patrones De DiseñO
 
Diagramas de interaccion - Cun Monteria
Diagramas de interaccion - Cun MonteriaDiagramas de interaccion - Cun Monteria
Diagramas de interaccion - Cun Monteria
 
0 todo
0 todo0 todo
0 todo
 
1 3 ingenieria software y patrones de diseño
1 3 ingenieria software y patrones de diseño1 3 ingenieria software y patrones de diseño
1 3 ingenieria software y patrones de diseño
 
Presentacion gozinto
Presentacion gozintoPresentacion gozinto
Presentacion gozinto
 
2.4 DISEÑO BASADO EN PATRONES.pptx
2.4 DISEÑO BASADO EN PATRONES.pptx2.4 DISEÑO BASADO EN PATRONES.pptx
2.4 DISEÑO BASADO EN PATRONES.pptx
 
12-150203140754-conversion-gate02.pptx
12-150203140754-conversion-gate02.pptx12-150203140754-conversion-gate02.pptx
12-150203140754-conversion-gate02.pptx
 
Juan velasquez
Juan velasquezJuan velasquez
Juan velasquez
 
12.diseño basado en patrones
12.diseño basado en patrones12.diseño basado en patrones
12.diseño basado en patrones
 
Metodologías para el Análisisy Diseño de Sistemas
Metodologías para el Análisisy Diseño de SistemasMetodologías para el Análisisy Diseño de Sistemas
Metodologías para el Análisisy Diseño de Sistemas
 
Metodologías para el Análisisy Diseño de Sistemas
Metodologías para el Análisisy Diseño de SistemasMetodologías para el Análisisy Diseño de Sistemas
Metodologías para el Análisisy Diseño de Sistemas
 
Analisis de sistemas
Analisis de sistemasAnalisis de sistemas
Analisis de sistemas
 
Slideshare 2do corte, luismortell
Slideshare 2do corte, luismortellSlideshare 2do corte, luismortell
Slideshare 2do corte, luismortell
 
Analisis de requerimiento
Analisis de requerimientoAnalisis de requerimiento
Analisis de requerimiento
 
Patrones de diseño I
Patrones de diseño IPatrones de diseño I
Patrones de diseño I
 
Metodologías para el desarrollo de sistemas
Metodologías para el desarrollo de sistemasMetodologías para el desarrollo de sistemas
Metodologías para el desarrollo de sistemas
 
METODOS Y MODELOS POO
METODOS Y MODELOS POOMETODOS Y MODELOS POO
METODOS Y MODELOS POO
 
Clase ii patrones de diseño
Clase ii patrones de diseñoClase ii patrones de diseño
Clase ii patrones de diseño
 
Introducción Patrones de Diseño
Introducción Patrones de DiseñoIntroducción Patrones de Diseño
Introducción Patrones de Diseño
 

Más de Fernando Alfonso Casas De la Torre

Congreso Internacional de Investigacion Universidad Cortazar 2018
Congreso Internacional de Investigacion Universidad Cortazar 2018Congreso Internacional de Investigacion Universidad Cortazar 2018
Congreso Internacional de Investigacion Universidad Cortazar 2018Fernando Alfonso Casas De la Torre
 
Relación universidad-gobierno: caso de remodelación de una dependencia federal
Relación universidad-gobierno:  caso de remodelación  de una dependencia federalRelación universidad-gobierno:  caso de remodelación  de una dependencia federal
Relación universidad-gobierno: caso de remodelación de una dependencia federalFernando Alfonso Casas De la Torre
 

Más de Fernando Alfonso Casas De la Torre (20)

Mi Cascarita Proyecto Colibri.ppt
Mi Cascarita Proyecto Colibri.pptMi Cascarita Proyecto Colibri.ppt
Mi Cascarita Proyecto Colibri.ppt
 
Proyecto enlace WiFi Comunidades rurales
Proyecto enlace WiFi Comunidades ruralesProyecto enlace WiFi Comunidades rurales
Proyecto enlace WiFi Comunidades rurales
 
Congreso Academy Journal Tepic 2019
Congreso Academy Journal Tepic 2019Congreso Academy Journal Tepic 2019
Congreso Academy Journal Tepic 2019
 
Academy Journal Morelia 2018
Academy Journal Morelia 2018Academy Journal Morelia 2018
Academy Journal Morelia 2018
 
Congreso Internacional de Investigacion Universidad Cortazar 2018
Congreso Internacional de Investigacion Universidad Cortazar 2018Congreso Internacional de Investigacion Universidad Cortazar 2018
Congreso Internacional de Investigacion Universidad Cortazar 2018
 
Congreso Academy Journal Celaya 2017
Congreso Academy Journal Celaya 2017Congreso Academy Journal Celaya 2017
Congreso Academy Journal Celaya 2017
 
IMSS Informatica Actividades 2014 enfriamiento de site
IMSS Informatica Actividades 2014 enfriamiento de siteIMSS Informatica Actividades 2014 enfriamiento de site
IMSS Informatica Actividades 2014 enfriamiento de site
 
Historia de las Videoconsolas
Historia de las VideoconsolasHistoria de las Videoconsolas
Historia de las Videoconsolas
 
Relación universidad-gobierno: caso de remodelación de una dependencia federal
Relación universidad-gobierno:  caso de remodelación  de una dependencia federalRelación universidad-gobierno:  caso de remodelación  de una dependencia federal
Relación universidad-gobierno: caso de remodelación de una dependencia federal
 
Teorema de Naives Bayes
Teorema de Naives BayesTeorema de Naives Bayes
Teorema de Naives Bayes
 
Analisis de incendios forestales mediante WEKA
Analisis de incendios forestales mediante WEKAAnalisis de incendios forestales mediante WEKA
Analisis de incendios forestales mediante WEKA
 
Introduccion a mineria de datos
Introduccion a mineria de datosIntroduccion a mineria de datos
Introduccion a mineria de datos
 
Patron observador
Patron observadorPatron observador
Patron observador
 
Replicación de Bases de Datos con SQL Server 2008
Replicación de Bases de Datos con SQL Server 2008Replicación de Bases de Datos con SQL Server 2008
Replicación de Bases de Datos con SQL Server 2008
 
Patron Singleton
Patron SingletonPatron Singleton
Patron Singleton
 
Incorporacion a la Seguridad Social
Incorporacion a la Seguridad SocialIncorporacion a la Seguridad Social
Incorporacion a la Seguridad Social
 
Plan de Contingencia Informatico
Plan de Contingencia InformaticoPlan de Contingencia Informatico
Plan de Contingencia Informatico
 
Contingencia Informatica
Contingencia InformaticaContingencia Informatica
Contingencia Informatica
 
Las 10 leyes de la Seguridad Informatica
Las 10 leyes de la Seguridad InformaticaLas 10 leyes de la Seguridad Informatica
Las 10 leyes de la Seguridad Informatica
 
Comercializacion de un producto
Comercializacion de un productoComercializacion de un producto
Comercializacion de un producto
 

Patrones GRASP de tipo de bajo acoplamiento

  • 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