Proceso de Desarrollo OO
Analisis v.s. Diseño
• El Análisis pone énfasis en una
investigación del problema y los requisitos, en vez de ponerlo en la solución.
– Es adecuado clasificarlo como análisis de requisitos o análisis de los objetos del dominio.
– Se resume en la frase “hacer lo correcto”. – Se resume en la frase “hacer lo correcto”.
• El diseño pone énfasis en una solución conceptual que satisface los requisitos en vez de ponerlo en la implementación.
– Es adecuado clasificarlo como diseño de objetos.
Diseño
• La finalidad del Diseño orientado a objetos es definir los objetos
software y sus colaboraciones. Una manera habitual para ilustrar estas colaboraciones es el diagrama de Interacción (vista dinámica) y
Interacción (vista dinámica) y
Diseño
• El diseño orientado a objetos
presta especial atención a la
definición de objetos software
y en cómo colaboran para
Diseño
• El diseño de objetos se se
describe como:
Diseño
• La decisión de qué metodos,
donde colocarlos y cómo
deberían interactuar los objetos
es muy importante.
• Es una etapa crítica; es la parte
• Es una etapa crítica; es la parte
esencial de lo que entendemos
por desarrollar un sistema
Modelo de Diseño
• GRASP
• Diagramas de Interacción
(RCU).
GRASP
• Acrónimo de: General
Responsibility Assignment Software
Patterns. (Patrones generales de software par a asignar
responsabilidades). responsabilidades).
• El nombre sugiere la importancia de aprehender (grasping en ingles)
estos principios para diseñar con
¿Qué es un patrón? (1)
• Los desarrolladores orientados a objetos con experiencia acumulan un repertorio tanto de principios generales como de soluciones
basadas en aplicar ciertos estilos que basadas en aplicar ciertos estilos que les guían en la creación de software. • Estos estilis y principios puestos en
un formato estructurado que
describa el problema y la solución, y se les da un nombre, podrían
¿Qué es un patrón? (2)
• Un patrón es una descripción de un problema y la solución, a la que se da un nombre y que se puede
aplicar a nuevos contextos;
• idealmente proporciona consejos sobre el modo de aplicarlo en varias circunstancias y considera los
Qué es un patrón? (3)
• El término patrón sugiere algo repetitivo,
• El termino nuevo patrón podría considerarse un oxímoron.
Qué es un patrón? (4)
Resumiendo lo anterior (1)
• La asignación habilidosa de responsabilidades es
extremadamente importante en el diseño de objetos.
• La decisión acerca de la asignación • La decisión acerca de la asignación
de responsabilidades tiene lugar
durante la creación de los diagramas de interacción y con seguridad
Resumiendo lo anterior (2)
• Los patrones son pares
problema/solución con nombre que codifican buenos consejos y
principios relacionados con
frecuencia con la asignación de frecuencia con la asignación de responsabilidades.
• Los patrones GRASP describen los principios fundamentales del diseño de objetos y la asignación de
Los patrones GRASP son los
siguientes:
• Experto en Información. • Creador.
• Controlador.
• Bajo Acoplamiento (Evaluativo)
• Alta Cohesión
• Alta Cohesión (Evaluativo)
• Polimorfismo
• Fabricación Pura • Indirección
Experto en Información
• Problema:
– ¿Un principio general del diseño de objetos y la asignación de
responsabilidades?
• Solución:
– Asigne una responsabilidad al experto en información, -la clase que tiene la
Ejemplo:
• Problema
– ¿Quién debe tener la responsabilidad de permitir conocer el total de la venta?
Ejemplo: (2)
Ejemplo: (2)
Curiosidades sobre Experto en
Información.
• En el campo del software orientado a objetos, todos los objetos están
“vivos” o “animados”, y pueden tener responsabilidades o hacer cosas.
• Hacen cosas relacionadas con la información que conocen, yo lo denomino el principio de
Creador
• Problema:
– ¿Qué objeto debería crear otro(s) objeto(s)?
• Solución:
– Asigne a la clase B la responsabilidad de
crear una instancia de la clase A si se cumple alguno de los puntos siguientes:
crear una instancia de la clase A si se cumple alguno de los puntos siguientes:
• B contiene a A • B agrega a A
• B tiene los datos de inicialización de A (Experto en A)
• B registra a A
Patrones relacionados
• Bajo Acoplamiento
• Factoría
Ejemplo:
• Cuando se realice un pago
¿Qué clase debería crear la
instancia de Pago y asociarla
con la Venta?
Ejemplo:
Ejemplo:
Ejemplo:
Ejemplo:
• ¿Cuál solución es más
adecuada?
A
Ejemplo:
• El patrón que veremos a
continuación nos ayudará a
decidir:
Bajo Acoplamiento
• Problema:
– ¿Cómo dar soporte a las bajas
dependencias y al incremento de la reutilización?
• Solución:
¿Cuándo existe acoplamiento?
• El tipoX tiene un atributo que hace referencia a
una instancia de tipoY.
• Un objeto de tipoX invoca los servicios de un
objeto de tipoY.
• El tipoX tiene un método que comprende un
• El tipoX tiene un método que comprende un
parámetro de tipoY o el objeto de retorno sea
una instancia del tipoY.
• El tipoX es una subclase, directa o indirecta del
tipoY.
• El tipoY es una interfaz y el tipoX implementa
Ejemplo:
Ejemplo:
• ¿Cuál solución es más adecuada?, en otras palabras…
• ¿Qué solución presenta menor acoplamiento?
A
Alta Cohesión
• Problema:
– ¿Cómo mantener la complejidad manejable?
• Solución:
– Asigne responsabilidades de manera que la cohesión
¿Cuándo se tiene cohesión?
• La cohesión es una medida de la fuerza con que se relacionan y el grado en que se focalizan las
responsabilidades de un elemento.
• Un elemento con responsabilidades altamente relacionadas y que no
Ejemplo
• ¿Qué diseño favorece más la cohesión?
A A
Alta Cohesión
• Como regla empírica, una clase
con alta cohesión tiene un
número relativamente pequeño
de metodos, con funcionalidad
altamente relacionada y no
altamente relacionada y no
realiza mucho trabajo.
El Yin y el Yang
• Una mala cohesión causa
normalmente un mal acoplamiento y viceversa.
• Imagine una clase que dibuja un • Imagine una clase que dibuja un
elemento GUI, maneja sus eventos, almacena datos en BD e invoca
servicio de objetos remotos. (no cohesiva y muy acoplada a
Controlador
• Problema:
– ¿Quién gestiona un evento del sistema?
• Solución:
– Asigne la responsabilidad de gestionar un mensaje o evento del sistema a una – Asigne la responsabilidad de gestionar
un mensaje o evento del sistema a una clase que represente una de estas dos opciones:
• Representa el sistema global, dispositivo o un subsistema (controlador de
fachada)
• Representa un escenario de caso de uso en el que tiene lugar el evento del
¿Evento del sistema?
• Cuando un cajero utiliza un
terminal de PDV y presiona el botón “Finalizar Venta”, esta generando un evento del sistema para que el sistema ejecute el cierre de la venta. sistema ejecute el cierre de la venta.
• Cuando un escritor utiliza in
procesador de texto y presiona el
botón “Comprobar Ortografía”, esta generando un evento del sistema,
Controlador
• Un
evento del sistema
de
entrada es un evento generado
por un actor externo.
• Evento del sistema ≡ Operación del sistema
Controlador
• Un controlador
NO
es un
objeto que pertenece a la
interfaz de usuario.
• Los elementos GUI deben
delegar el manejo de
Controlador de fachada
Controlador de caso de uso o
sesión
Ejemplo:
Importante
• La aplicación no tiene que tener obligatoriamente un solo
controlador de fachada saturado, puede utilizar controladores de casos de uso.
casos de uso.
• Diseñe el controlador de manera que, ante todo, delegue el
cumplimiento de cada
Ejemplo y ejercicio
• Comente los siguientes
diagramas de Interacción sobre
su cumplimento en cuanto a
patrones de diseño.
patrones de diseño.
• Realice una réplica de los
mismos utilizando la
Diagrama de Colaboración
object Carreras
:Administra dorCarrera s c :Ca rrer a
introducirDatosDeCarrera(idCarrera, nombre)
1: crearCarrera(idCarrera, nombre)
:Car rera s
Diagrama de Colaboración
object Alumno
:Administra dorCarrera s :Car rer a a :Alumno
introducirDatosDeAlumno(nControl, nombre, direccion, idCarrera)
2: introducirDatosDeAlumno(nControl, nombre, direccion) 3: crear(nControl, nombre, direccion)
:Car rera s
:Alumnos :CatalogoAlumnos
1: carrera= buscar(idCarrera)
3.1: añadir(a)
