Patrones Básicos de Asignación de …isis2603/...• Dos clases de responsabilidades –Conocer...
68
Departamento de Ingeniería de Sistemas y Computación - Universidad de los Andes | Nivelatorio de Modelaje Facultad de Ingeniería Departamento de Ingeniería de Sistemas y Computación Patrones Básicos de Asignación de Responsabilidades 1 Introducción
Transcript of Patrones Básicos de Asignación de …isis2603/...• Dos clases de responsabilidades –Conocer...
Departamento de Ingeniería de Sistemas y Computación - Universidad de los Andes | Nivelatorio de Modelaje
Facultad de Ingeniería
Departamento de Ingeniería de Sistemas y
Computación
Patrones Básicos de Asignación de
Responsabilidades
1
Introducción
Departamento de Ingeniería de Sistemas y Computación - Universidad de los Andes | Nivelatorio de Modelaje
Motivación
• En los módulos anteriores hemos visto
cómo utilizando diagramas de clases
podemos representar la estructura
estática de un sistema.
2
Departamento de Ingeniería de Sistemas y Computación - Universidad de los Andes | Nivelatorio de Modelaje
Motivación• En los módulos anteriores hemos visto cómo
utilizando diagramas de clases podemos
representar la estructura estática de un sistema.
• Esta estructura está definida por un conjunto de
clases relacionadas entre ellas.
3
Departamento de Ingeniería de Sistemas y Computación - Universidad de los Andes | Nivelatorio de Modelaje
Motivación
4
Departamento de Ingeniería de Sistemas y Computación - Universidad de los Andes | Nivelatorio de Modelaje
Motivación
5
Supongamos que tenemos un
objeto, que llamaremos o1,
instancia de esta clase
nombre=“Los Andes”
o1:Universidad
nit=“12234”
Departamento de Ingeniería de Sistemas y Computación - Universidad de los Andes | Nivelatorio de Modelaje
Motivación
6
El objeto o1 tiene valores en
los atributos nombre y nit que
son los atributos definidos en
la clase.
nombre=“Los Andes”
o1:Universidad
nit=“12234”
Departamento de Ingeniería de Sistemas y Computación - Universidad de los Andes | Nivelatorio de Modelaje
Motivación
7
Si queremos conocer el valor
del atributo nombre del objeto
o1, decimos que le enviamos
a o1 el mensaje darNombre()
nombre=“Los Andes”
o1:Universidad
nit=“12234”darNombre()
Departamento de Ingeniería de Sistemas y Computación - Universidad de los Andes | Nivelatorio de Modelaje
Motivación• Para que un objeto pueda realizar algo, su
comportamiento debe estar definido en un
método de la clase que lo creó, es decir, la clase
de la cual el objeto es una instancia.
• En el ejemplo, anterior, el objeto o1, instancia de
Universidad, puede devolver el nombre, dado
que este método darNombre() está definido en
la clase Universidad.
8
Departamento de Ingeniería de Sistemas y Computación - Universidad de los Andes | Nivelatorio de Modelaje
Motivación
• En el ejemplo anterior, para la realización de la tarea
darNombre únicamente se necesita la información que
contiene el objeto de la clase Universidad (el valor de su
atributo privado).
• Sin embargo, en muchas ocasiones, para realizar una
acción o una tarea se necesita conocer la información
que está en varios objetos posiblemente instancias de
distintas clases.
9
Departamento de Ingeniería de Sistemas y Computación - Universidad de los Andes | Nivelatorio de Modelaje
Motivación• Dicho de otra forma, cuando construimos
modelos orientados-objetos uno de los retos
más importantes es decidir de quién es la
responsabilidad de realizar alguna acción.
• Estas decisiones responden a las preguntas:
– “¿En cuál clase se debe definir tal o cuál método?” o
– “ ¿De quién es la responsabilidad de ocuparse de tal
o cuál acción?”
10
11
Si tenemos este diagrama de
clases podemos preguntarnos:
• ¿Quién es el responsable de
crear un nuevo estudiante?
• ¿Quién es el responsable de
calcular cuáles son los
créditos totales de un
programa dado?
• ¿Quién es el responsable de
cambiar la información sobre
una universidad?
• ¿Quién es el responsable de
informar cuántas mujeres hay
inscritas en un curso?
Motivación
Departamento de Ingeniería de Sistemas y Computación - Universidad de los Andes | Nivelatorio de Modelaje
Motivación
• En que consiste la responsabilidad?
– Obligaciones o contratos de una clase
12
Departamento de Ingeniería de Sistemas y Computación - Universidad de los Andes | Nivelatorio de Modelaje
Motivación
• Dos clases de responsabilidades
– Conocer
• Conocer la información privada del objeto
• Conocer acerca de los objetos relacionados
• Conocer acerca de lo que se puede calcular o
derivar
– Hacer
• Realizar algo él mismo
• Iniciar acciones en otros objetos
• Controlar o coordinar actividades en otros
objetos.13
14
Responsabilidades de conocer:
• ¿Cuáles son los créditos
totales de un programa
dado?
• ¿Cuántas mujeres hay
inscritas en un curso?
Motivación
15
Responsabilidades de hacer:
• Crear un nuevo estudiante.
• Cambiar la información sobre
una universidad
Motivación
Departamento de Ingeniería de Sistemas y Computación - Universidad de los Andes | Nivelatorio de Modelaje
GRASP
Para ayudar a resolver preguntas como las
anteriores existen los patrones generales
de software para asignación de
responsabilidades, es el acrónimo de
"GRASP (object-oriented design General
Responsibility Assignment Software 16
Departamento de Ingeniería de Sistemas y Computación - Universidad de los Andes | Nivelatorio de Modelaje
GRASP
• El primero en hablar de estos
patrones de asignación de
responsabilidades básicos fue Craig
Larman quien ha escrito varios
libros sobre el tema:
17
http://en.wikipedia.org/wiki/Craig_Larman
1997 - Applying UML and Patterns - ISBN 0-13-
748880-7
2001 - Applying UML and Patterns: An Introduction to
Object-Oriented Analysis and Design and the Unified
Process - ISBN 0-13-092569-1
2004 - Applying UML and Patterns: An Introduction to
Object-Oriented Analysis and Design and Iterative
Development - ISBN 0-13-148906-2
Departamento de Ingeniería de Sistemas y Computación - Universidad de los Andes | Nivelatorio de Modelaje
GRASP
• Estos patrones básicos o principios
básicos de asignación de
responsabilidades son unas guías o
buenas prácticas que nos ayudan a tomar
algunas decisiones de sobre en qué clase
definir un método.
18
Departamento de Ingeniería de Sistemas y Computación - Universidad de los Andes | Nivelatorio de Modelaje
GRASP
• Lo que queremos es que, al final de
cuentas, la decisión que tomemos nos
permita construir un sistema más
entendible y fácil de cambiar.
19
Departamento de Ingeniería de Sistemas y Computación - Universidad de los Andes | Nivelatorio de Modelaje20
• Vamos a estudiar algunos de estos
patrones:
– Bajo Acoplamiento
– Alta Cohesión
– Creador
– Experto
GRASP
Departamento de Ingeniería de Sistemas y Computación - Universidad de los Andes | Nivelatorio de Modelaje
Facultad de Ingeniería
Departamento de Ingeniería de Sistemas y
Computación
Patrones Básicos de Asignación de
Responsabilidades
Patrones: bajo acoplamiento, alta
cohesión, experto y creador
21
•22
Antes de hablar del patrón de bajo acoplamiento
debemos definir qué es acoplamiento en el contexto de
un diagrama de clases.
Departamento de Ingeniería de Sistemas y Computación - Universidad de los Andes | Nivelatorio de Modelaje
Acoplamiento
• Acoplamiento es la medida de cuánto una
clase esta conectada (tiene conocimiento)
de otras clases.
•23
Departamento de Ingeniería de Sistemas y Computación - Universidad de los Andes | Nivelatorio de Modelaje
Acoplamiento
•24
Johnatan rehacer esta figura con cajas que parezcan más clases y
flechas que parezcan más asociaciones y sin los títulos de abajo ni en
ningún lado
Departamento de Ingeniería de Sistemas y Computación - Universidad de los Andes | Nivelatorio de Modelaje
Acoplamiento
25
En la figura de la izquierda se puede apreciar que el número de relaciones entre estas clases es mayor que en el de la figura de la derecha.
Johnatan rehacer esta figura con cajas que parezcan más clases y flechas
que parezcan más asociaciones y sin los títulos de abajo ni en ningún lado
Departamento de Ingeniería de Sistemas y Computación - Universidad de los Andes | Nivelatorio de Modelaje
Acoplamiento
•26
Entonces decimos que el diagrama de la izquierda tiene un alto acoplamiento y el de la izquierda un bajo acoplamiento. O por lo menos, su acoplamiento es menor que el de la izquierda.
Departamento de Ingeniería de Sistemas y Computación - Universidad de los Andes | Nivelatorio de Modelaje
Acoplamiento
• Un alto acoplamiento en un sistema es
problemático porque, debido a la cantidad
de relaciones entre las clases, va a se
más difícil:
• Entender el sistema
• Cambiar el sistema
•27
Departamento de Ingeniería de Sistemas y Computación - Universidad de los Andes | Nivelatorio de Modelaje
Acoplamiento
• Cuando se necesite
cambiar un sistema
muy acoplado, por
ejemplo cambiar una
clase (por ejemplo la
que mostramos en
verde)
•28
Departamento de Ingeniería de Sistemas y Computación - Universidad de los Andes | Nivelatorio de Modelaje
Acoplamiento
• El impacto del cambio va a ser más difícil de evaluar y de realizar debido a las múltiples relaciones que esa clase pueda tener con las demás.
• Potencialmente todas las demás se pueden ver afectadas por el cambio.
•29
Departamento de Ingeniería de Sistemas y Computación - Universidad de los Andes | Nivelatorio de Modelaje
Patrón de Bajo Acoplamiento
• Este patrón nos dice que debemos tratar
de mantener el nivel de acoplamiento bajo
minimizando el conocimiento que unas
clases deben tener de otras.
•30
Departamento de Ingeniería de Sistemas y Computación - Universidad de los Andes | Nivelatorio de Modelaje
Patrón de Bajo Acoplamiento
• Quiere decir que cuando tomamos una
decisión si esta decisión implica
establecer una nueva relación entre las
clases tenemos que evaluar si realmente
eso es necesario porque al hacerlo vamos
a aumentar el nivel de acoplamiento.
• No puede ser considerado aisladamente
pero sí es una guía para tomar decisiones.
•31
Departamento de Ingeniería de Sistemas y Computación - Universidad de los Andes | Nivelatorio de Modelaje
Patrón de Bajo Acoplamiento
• Es un patrón evaluativo:
– un bajo acoplamiento permite que el diseño
de clases sea más independiente.
– Reduce el impacto de los cambios y aumenta
la reutilización.
•32
Departamento de Ingeniería de Sistemas y Computación - Universidad de los Andes | Nivelatorio de Modelaje
Cohesión
• Vamos a explicar el concepto de Cohesión
utilizando como ejemplo la navaja de la
figura.
• Esta navaja tiene muchas funciones
(responsabilidades en nuestros términos).
• Esta sirve como tijeras, cortador, lupa,
lima, sierra, abridor de botellas,
destornillador, pinzas, etc.
•33
Departamento de Ingeniería de Sistemas y Computación - Universidad de los Andes | Nivelatorio de Modelaje
Cohesión
• En este caso diríamos que esta navaja no es muy “cohesiva” ya que se ocupa de demasiadas funciones distintas en el mismo aparato.
• Esas funciones no están relacionadas entre sí.
• Fíjese que para cada una de ellas hay un elemento distinto que se ha agregado a la navaja.
• Si debo contestar qué hace la navaja? La respuesta no es simple, debo contestar utilizando muchos verbos.
•34
Departamento de Ingeniería de Sistemas y Computación - Universidad de los Andes | Nivelatorio de Modelaje
Cohesión
• Cohesión funcional dentro de una clase es una medida que indica cuán relacionadas están las responsabilidades de una clase entre sí.
• Entre más relacionadas estén las responsabilidades de una clase más fácil será entender la clase y en general todo el sistema.
• Significa que cuando el sistema se deba cambiar, más fácil será encontrar dónde hacer el cambio.
•35
Departamento de Ingeniería de Sistemas y Computación - Universidad de los Andes | Nivelatorio de Modelaje
Alta Cohesión
• Este patrón nos dice que debemos tratar
de mantener el nivel de cohesión al
interior de una clase lo más alto posible.
• Es un patrón evaluativo:
– entre más alta cohesión más fácil de
entender, de cambiar, de reutilizar.
•36
Departamento de Ingeniería de Sistemas y Computación - Universidad de los Andes | Nivelatorio de Modelaje
Alta Cohesión
• Volviendo al ejemplo de la navaja, la de
esta figura es mucho más cohesiva
porque tiene una sola función: “cortar”.
• No puede ser considerado aisladamente
pero sí es una guía para tomar decisiones.
•37
Departamento de Ingeniería de Sistemas y Computación - Universidad de los Andes | Nivelatorio de Modelaje
Patrón Experto
• Cada objeto es responsable por mantener su propia información (principio de encapsulamiento):
– conoce y puede informar el valor de sus atributos
– puede modificar el valor de sus atributos
• Uno espera que los atributos de una clase sean privados o protegidos, que nunca sean públicos.
•38
Departamento de Ingeniería de Sistemas y Computación - Universidad de los Andes | Nivelatorio de Modelaje
Patrón Experto
• Si tiene relaciones de composición con
otros objetos (sus partes),
– también será responsable de conocer la
información de ellos, de crearlos (Creator
pattern) y de delegarles las operaciones.
•39
Departamento de Ingeniería de Sistemas y Computación - Universidad de los Andes | Nivelatorio de Modelaje
Patrón Experto
•40
Retomemos una parte de nuestro ejemplo
de “Universidad”.
Supongamos que debemos decidir:
1. De quién es la responsabilidad de
cambiar la información del nombre y el
nit de las instancias de la clase
Universidad?
2. De quién es la responsabilidad de
saber cuántos estudiantes hay en total
en una universidad?
3. De quién es la responsabilidad de
saber cuál es el promedio de edad de
todos los estudiantes de una
universidad?
Patrón Experto
•41
Para responder la pregunta utilizamos el
patrón experto.
1. De quién es la responsabilidad de
cambiar la información del nombre y
el nit de las instancias de la clase
Universidad?
Patrón Experto
•42
La respuesta es la clase Universidad
porque ella es la dueña de esa
información
Para responder la pregunta utilizamos el
patrón experto.
1. De quién es la responsabilidad de
cambiar la información del nombre y
el nit de las instancias de la clase
Universidad?
Patrón Experto
•43
Significa que, utilizando
como guía el patrón experto,
a la clase Universidad le
hemos agregado los
siguientes métodos que
corresponden a la
manipulación de la
información que le
pertenece:
Patrón Experto
•44
Para la pregunta número 2, también
utilizamos el patrón experto.
2. De quién es la responsabilidad de
saber cuántos estudiantes hay en
total en una universidad?
Patrón Experto
•45
Note que la clase Universidad a través
de la relación de composición.
Es la dueña de la colección estudiantes.
Entonces, siguiendo la guía del patrón
experto, la responsabilidad de saber
cuántos estudiantes hay en una
universidad es de la clase Universidad.
Para la pregunta número 2, también
utilizamos el patrón experto.
2. De quién es la responsabilidad de
saber cuántos estudiantes hay en
total en una universidad?
Patrón Experto
•46
Note que la clase Universidad a través
de la relación de composición.
Es la dueña de la colección estudiantes.
Entonces, siguiendo la guía del patrón
experto, la responsabilidad de saber
cuántos estudiantes hay en una
universidad es de la clase Universidad.
Para la pregunta número 2, también
utilizamos el patrón experto.
2. De quién es la responsabilidad de
saber cuántos estudiantes hay en
total en una universidad?
Patrón Experto
•47
Note que la clase Universidad a través
de la relación de composición.
Es la dueña de la colección estudiantes.
Entonces, siguiendo la guía del patrón
experto, la responsabilidad de saber
cuántos estudiantes hay en una
universidad es de la clase Universidad.
Para la pregunta número 2, también
utilizamos el patrón experto.
2. De quién es la responsabilidad de
saber cuántos estudiantes hay en
total en una universidad?
Patrón Experto
•48
Note que la clase Universidad a través
de la relación de composición.
Es la dueña de la colección estudiantes.
Entonces, siguiendo la guía del patrón
experto, la responsabilidad de saber
cuántos estudiantes hay en una
universidad es de la clase Universidad.
Para la pregunta número 2, también
utilizamos el patrón experto.
2. De quién es la responsabilidad de
saber cuántos estudiantes hay en
total en una universidad?
Patrón Experto
•49
Para responder la tercera pregunta
también utilizamos el patrón experto.
3. De quién es la responsabilidad de
saber cuál es el promedio de edad de
todos los estudiantes de una
universidad?
Patrón Experto
•50
Para responder la tercera pregunta
también utilizamos el patrón experto.
3. De quién es la responsabilidad de
saber cuál es el promedio de edad de
todos los estudiantes de una
universidad?
En este caso, tenemos que la clase
Estudiante es la dueña de la información
de la edad.
Patrón Experto
•51
Para responder la tercera pregunta
también utilizamos el patrón experto.
3. De quién es la responsabilidad de
saber cuál es el promedio de edad de
todos los estudiantes de una
universidad?
Cada objeto de la clase Estudiante tiene
la responsabilidad de conocer el valor de
su atributo edad.
Esta responsabilidad se ve reflejada en
un nuevo método en la clase Estudiante:
darEdad()
Patrón Experto
•52
Para responder la tercera pregunta
también utilizamos el patrón experto.
3. De quién es la responsabilidad de
saber cuál es el promedio de edad de
todos los estudiantes de una
universidad?
Pero lo que se necesita es calcular el
promedio de edad de todos los
estudiantes en la colección estudiantes
que le pertenece a la universidad.
Patrón Experto
•53
Para responder la tercera pregunta
también utilizamos el patrón experto.
3. De quién es la responsabilidad de
saber cuál es el promedio de edad de
todos los estudiantes de una
universidad?
Siguiendo el mismo razonamiento de la
pregunta anterior, podemos concluir que
el responsable de este cálculo debe ser
un nuevo método en la clase
Universidad.
Departamento de Ingeniería de Sistemas y Computación - Universidad de los Andes | Nivelatorio de Modelaje
Patrón Experto
•54
Para responder la tercera pregunta
también utilizamos el patrón experto.
3. De quién es la responsabilidad de
saber cuál es el promedio de edad de
todos los estudiantes de una
universidad?
Para realizar su tarea, este nuevo
método va a tener que utilizar el método
darEdad() de la clase Estudiante
Conclusiones…
•55
Note que con el patrón experto:
– estamos construyendo clases cohesivas
porque las responsabilidades que estamos
definiendo hacen referencia a acciones que
manipulan sus propias propiedades.
– No estamos aumentando el acoplamiento
entre clases porque no estamos definiendo
relaciones nuevas entre las clases a las que
les estamos definiendo las responsabilidades.
Departamento de Ingeniería de Sistemas y Computación - Universidad de los Andes | Nivelatorio de Modelaje
Patrón Creador
• El patrón creador es una especialización
del patrón experto.
• Este patrón nos ayuda a guiar la decisión
de quién debe crear un objeto de otra
clase.
• La guía es la siguiente con prioridad en el
orden que se presenta:
56
56
Departamento de Ingeniería de Sistemas y Computación - Universidad de los Andes | Nivelatorio de Modelaje
Patrón Creador
Un objeto de la clase B tiene la responsabilidad
de crear objetos de la clase A si:
1. La clase B tiene una relación de composición
con la clase A
57
57
Departamento de Ingeniería de Sistemas y Computación - Universidad de los Andes | Nivelatorio de Modelaje
Patrón Creador
Un objeto de la clase B tiene la responsabilidad
de crear objetos de la clase A si:
1. La clase B tiene una relación de composición
con la clase A
2. La clase B agrega objetos de la clase A
58
58
Departamento de Ingeniería de Sistemas y Computación - Universidad de los Andes | Nivelatorio de Modelaje
Patrón Creador
Un objeto de la clase B tiene la responsabilidad
de crear objetos de la clase A si:
1. La clase B tiene una relación de composición
con la clase A
2. La clase B agrega objetos de la clase A
3. B usa (exhaustivamente) objetos A
59
59
Departamento de Ingeniería de Sistemas y Computación - Universidad de los Andes | Nivelatorio de Modelaje
Patrón Creador
Un objeto de la clase B tiene la responsabilidad de crear objetos de la clase A si:
1. La clase B tiene una relación de composición con la clase A
2. La clase B agrega objetos de la clase A
3. B usa (exhaustivamente) objetos A
4. B posee la información necesaria para inicializar A
60
60
Departamento de Ingeniería de Sistemas y Computación - Universidad de los Andes | Nivelatorio de Modelaje
Patrón Creador
• Con esa guía, lo que se busca es evitar crear nuevas dependencias entre las clases.
• Estamos indicando que ya hay asociaciones establecidas entre estas dos clases y que estamos buscando la responsabilidad de creación entre clases muy cercanas.
61
61
Departamento de Ingeniería de Sistemas y Computación - Universidad de los Andes | Nivelatorio de Modelaje
Patrón Creador
Suponga ahora que
tenemos un diagrama
como este en donde la
clase C no está
relacionada con la clase A
62
62
Departamento de Ingeniería de Sistemas y Computación - Universidad de los Andes | Nivelatorio de Modelaje
Patrón Creador
63
Si decidiéramos que la clase C es responsable de crear objetos de la clase A… estaríamos estableciendo una nueva dependencia en el diagrama y por lo tanto aumentaríamos el acoplamiento.
63
Departamento de Ingeniería de Sistemas y Computación - Universidad de los Andes | Nivelatorio de Modelaje
Patrón Creador
64
Si decidiéramos que la clase C es responsable de crear objetos de la clase A… estaríamos estableciendo una nueva dependencia en el diagrama y por lo tanto aumentaríamos el acoplamiento.
64
Departamento de Ingeniería de Sistemas y Computación - Universidad de los Andes | Nivelatorio de Modelaje
Patrón Creador
Siguiendo con nuestro
ejemplo, podemos decidir
que:
La clase Universidad es la
responsable de crear
objetos de la clase
Estudiante.
Porque Universidad tiene
una asociación de
composición con
Estudiante.
65
65
Patrón Creador
•66
• Del ejemplo, también tenemos que como entre la clase Programa y la clase Curso hay una asociación de composición entonces decidimos que la clase Programa será la responsable del método de creación de los cursos.
Departamento de Ingeniería de Sistemas y Computación - Universidad de los Andes | Nivelatorio de Modelaje
Patrón Creador
• Fíjese que si dijéramos que es la clase Universidad la responsable del método de creación de los cursos
•67
Departamento de Ingeniería de Sistemas y Computación - Universidad de los Andes | Nivelatorio de Modelaje
Patrón Creador
•68
Estaríamos estableciendo una nueva relación entre Universidad y Curso (antes no existía) y de esa forma estaríamos aumentando el acoplamiento del diagrama.
