Proceso de Desarrollo OO

Enfoque prctico propuesto por Craig Larman

Fases y disciplinas

Analisis y Diseo en el UP

Marco de Desarrollo

Analisis v.s. Diseo

El Anlisis pone nfasis en una investigacin del problema y los requisitos, en vez de ponerlo en la solucin.
Es adecuado clasificarlo como anlisis de requisitos o anlisis de los objetos del dominio. Se resume en la frase hacer lo correcto.

El diseo pone nfasis en una solucin conceptual que satisface los requisitos en vez de ponerlo en la implementacin.
Es adecuado clasificarlo como diseo de objetos. Se resume en la frase hacerlo correcto.

Diseo
La finalidad del Diseo orientado a objetos es definir los objetos software y sus colaboraciones. Una manera habitual para ilustrar estas colaboraciones es el diagrama de Interaccin (vista dinmica) y diagramas de clases de diseo (vista esttica).

Diseo

Modelo de Diseo

Diseo
El diseo orientado a objetos presta especial atencin a la definicin de objetos software y en cmo colaboran para satisfacer los requisitos.

Diseo
El diseo de objetos se se describe como: Despus de la identificacin de sus requisitos y la creacin del modelo del dominio, entonces aada mtodos a las clases del software, y defina el paso de mensajes entre los objetos para satisfacer los requisitos.

Diseo
La decisin de qu metodos, donde colocarlos y cmo deberan interactuar los objetos es muy importante. Es una etapa crtica; es la parte esencial de lo que entendemos por desarrollar un sistema orientado a objetos, no el dibujo de diagramas.

Modelo de Diseo
GRASP Diagramas de Interaccin (RCU). Diagrama de Clases de Diseo.

Cap. 6 Larman, pag. 73

GRASP
Acrnimo de: General Responsibility Assignment Software Patterns. (Patrones generales de software par a asignar responsabilidades). El nombre sugiere la importancia de aprehender (grasping en ingles) estos principios para disear con xito el software orientado a objetos.

Qu es un patrn? (1)
Los desarrolladores orientados a objetos con experiencia acumulan un repertorio tanto de principios generales como de soluciones basadas en aplicar ciertos estilos que les guan en la creacin de software. Estos estilis y principios puestos en un formato estructurado que describa el problema y la solucin, y se les da un nombre, podran llamarse patrones.

Ejemplo de Patrn

Qu es un patrn? (2)
Un patrn es una descripcin de un problema y la solucin, 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 puntes fuertes y compromisos.

Qu es un patrn? (3)
El trmino patrn sugiere algo repetitivo, El termino nuevo patrn podra considerarse un oxmoron. Los patrones pretenden registrar conocimiento, estilos y principios existentes, probados y validados; cuanto ms trillados y extendidos mejor.

Qu es un patrn? (4)
Los patrones facilitan la comunicacin:

Resumiendo lo anterior (1)

La asignacin habilidosa de responsabilidades es extremadamente importante en el diseo de objetos. La decisin acerca de la asignacin de responsabilidades tiene lugar durante la creacin de los diagramas de interaccin y con seguridad durante la programacin.

Resumiendo lo anterior (2)

Los patrones son pares problema/solucin con nombre que codifican buenos consejos y principios relacionados con frecuencia con la asignacin de responsabilidades. Los patrones GRASP describen los principios fundamentales del diseo de objetos y la asignacin de responsabilidades expresados como patrones.

Los patrones GRASP son los siguientes:

Experto en Informacin. Creador. Controlador. Bajo Acoplamiento (Evaluativo) Alta Cohesin (Evaluativo) Polimorfismo Fabricacin Pura Indireccin Variaciones Protegidas.

Experto en Informacin
Problema:
Un principio general del diseo de objetos y la asignacin de responsabilidades?

Solucin:
Asigne una responsabilidad al experto en informacin, -la clase que tiene la informacin necesaria para llevar a cabo la responsabilidad.

Ejemplo:
Problema
Quin debe tener la responsabilidad de permitir conocer el total de la venta?
Qu responsabilidades debemos asignar a cada clase para conocer el total de la venta?

Ejemplo: (2)
Reconociendo expertos en informacin

Ejemplo: (2)
Diagrama de Colaboracin

Curiosidades sobre Experto en Informacin.

En el campo del software orientado a objetos, todos los objetos estn vivos o animados, y pueden tener responsabilidades o hacer cosas. Hacen cosas relacionadas con la informacin que conocen, yo lo denomino el principio de animacin, es como estar en unos dibujos animados donde todo esta vivo.

Creador
Problema:
Qu objeto debera crear otro(s) objeto(s)?

Solucin:
Asigne a la clase B la responsabilidad de 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 inicializacin de A (Experto en A) B registra a A B utiliza estrechamente a A.

Patrones relacionados
Bajo Acoplamiento Factora Todo-Parte

Ejemplo:
Cuando se realice un pago Qu clase debera crear la instancia de Pago y asociarla con la Venta?

Ejemplo:
Clases involucradas

Ejemplo:
Solucin A

Ejemplo:
Solucin B

Ejemplo:
Cul solucin es ms adecuada?

Ejemplo:
El patrn que veremos a continuacin nos ayudar a decidir: Bajo Acoplamiento

Bajo Acoplamiento
Problema:
Cmo dar soporte a las bajas dependencias y al incremento de la reutilizacin?

Solucin:
Asigne responsabilidades de manera que el acoplamiento (innecesario se mantenga bajo).

Cundo 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 mtodo que comprende un parmetro 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 esa interfaz.

Ejemplo:
Qu solucin presenta menor acoplamiento?

Ejemplo:
Cul solucin es ms adecuada?, en otras palabras Qu solucin presenta menor acoplamiento?

Alta Cohesin
Problema:
Cmo mantener la complejidad manejable?

Solucin:
Asigne responsabilidades de manera que la cohesin permanezca alta.

Cundo se tiene cohesin?

La cohesin 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 hace una gran cantidad de trabajo, tiene alta cohesin.

Ejemplo
Qu diseo favorece ms la cohesin?
A

Alta Cohesin
Como regla emprica, una clase con alta cohesin tiene un nmero relativamente pequeo de metodos, con funcionalidad altamente relacionada y no realiza mucho trabajo. Colabora con otros objetos para compartir el esfuerzo si la tarea es extensa.

El Yin y el Yang
Una mala cohesin causa normalmente un mal acoplamiento y viceversa. 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 elementos con nada en comn)

Controlador
Problema:
Quin gestiona un evento del sistema?

Solucin:
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 sistema (controlador de caso de uso o sesin)

Evento del sistema?

Cuando un cajero utiliza un terminal de PDV y presiona el botn Finalizar Venta, esta generando un evento del sistema para que el
sistema ejecute el cierre de la venta.

Cuando un escritor utiliza in procesador de texto y presiona el botn Comprobar Ortografa, esta generando un evento del sistema,
para que el sistema ejecute

Controlador
Un evento del sistema de entrada es un evento generado por un actor externo.
Evento del sistema Operacin del sistema

Los DSS entran en juego

Controlador
Un controlador NO es un objeto que pertenece a la interfaz de usuario. Los elementos GUI deben delegar el manejo de operaciones al controlador respectivo, el cul delegar a su vez dicha operacin.

Ejemplo:

Qu clase deber gestionar los eventos del sistema para el caso de uso Procesar Venta?

Controlador de fachada
Representa el sistema global, dispositivo o un subsistema.

Controlador de caso de uso o sesin

Representa un escenario de caso de uso en el que tiene lugar el evento del sistema.

Ejemplo:
Suponga que elige crear una clase controlador del tipo fachada y esta es la clase Registro.

Ejemplo:

Congruencia con los contratos de Operacin

Importante
La aplicacin no tiene que tener obligatoriamente un solo controlador de fachada saturado, puede utilizar controladores de casos de uso. Disee el controlador de manera que, ante todo, delegue el cumplimiento de cada responsabilidad a otros objetos.

Diagrama de Clases de Diseo

Ejemplo y ejercicio
Comente los siguientes diagramas de Interaccin sobre su cumplimento en cuanto a patrones de diseo. Realice una rplica de los mismos utilizando la herramienta de modelado.

Diagrama de Colaboracin
object Carreras introducirDatosDeCarrera(idCarrera, nombre) 1: crearCarrera(idCarrera, nombre) c :Ca rrer a

:Administra dorCarrera s

2: aadir(c)

:Car rera s

Diagrama de Colaboracin
object Alumno introducirDatosDeAlumno(nControl, nombre, direccion, idCarrera) 2: introducirDatosDeAlumno(nControl, nombre, direccion) 3: crear(nControl, nombre, direccion)

:Administra dorCarrera s

:Car rer a

a :Alumno

3.1: aadir(a) 1: carrera= buscar(idCarrera) :CatalogoAlumnos :Car rera s 3.2: aadir(a)

:Alumnos

Arranque del sistema

Arranque del sistema