Este documento presenta los conceptos fundamentales del diseño de objetos. Explica que el diseño de objetos determina cómo la aplicación interactuará con los usuarios de acuerdo con los casos de uso definidos. También describe las herramientas como diagramas de clases, diagramas de interacción y diagramas de estados que se utilizan en el diseño de objetos. Finalmente, introduce el patrón de diseño de estados que separa la implementación de los comportamientos de un objeto según su estado.

1. Diseño:
Diseño de Objetos
Lic. César Alcántara Loayza

2. Términos
 Application logic: Software cuya principal
función es controlar las interacciones con el actor
manejando el comportamiento de la interface de
usuario.
 Transaction logic: Unidad de trabajo
estandarizada, reusable que puede ser referida por
cualquier número de aplicaciones. Por ejemplo
una transacción de “deposito” puede ser accedida
vía una aplicación ATM, home banking u otra
aplicación de cajero..
CAL/Fundamentos 2

3. Introducción
 Su aplicación (sistema) debería hacer lo que el
usuario espera que haga. El diseño de objetos
es la fase en la cual ud. decide como hace su
aplicación para que concuerde con estas
espectativas.
 Se han definido estas espectativas en el inicio
del proyecto usando los casos de uso. Ud. ha
definido todos los recursos que el sistema
necesita manejar, durante el análisis del
problema usando el modelo de objetos y los
diagramas de interacción.
CAL/Fundamentos 3

4. Introducción
 Durante el análisis arquitectural ud.
particionó el sistema en unidades
basadas en los casos de uso del
dominio del problema (particiones de
dominio) y la arquitectura mas
adecuada para soportar los objetivos
del sistema.
CAL/Fundamentos 4

5. Introducción
 Ahora en la fase de diseño de objetos
se trabajará en cada partición para
definir los mecanismos de control
dentro del software y las interfaces
entre estas piezas de software.
CAL/Fundamentos 5

6. Herramientas – Diseño de O.
 Ya hemos usado la mayoría de herramientas
del diseño de objetos:
 El modelo de objetos
 Los diagramas de interacción
 Especificacion de CUS (Narrativa - escenarios)
 Continuaremos usando estas herramientas.
Pero ahora añadiremos diferentes detalles a los
diagramas. Adicionalmente usaremos el
diagrama de estados para modelar el ciclo de
vida de los objetos y comportamientos
específicos al estado.
CAL/Fundamentos 6

7. Productos Trabajo Del Diseño
5
Modelo de
4 Objetos 6
escenario
s
1 3 7
2 Diagrama
Modelo de Especificacion
10 De Estados
casos de uso CUS
9
Diagrama de
11 Secuencia 8
Colaboración
CAL/Fundamentos 7

8. Productos Trabajo Del Diseño
 1. El modelo de casos de uso identifica
la comunicación entre los actores y el
sistema. El díalogo es la base para los
diagramas de interacción. Los recursos
usados para soportar el diálogo vienen
a ser los objetos del modelo de objetos.
CAL/Fundamentos 8

9. Productos Trabajo Del Diseño
 2. La descripción de los casos de uso
se pueden modelar usando la
especificación narrativa, modelo de
análisis y diagramas colaboración que
definan la lógica en la interacción entre
los actores y el sistema. La evaluación
de la lógica podría resultar en cambios
al alcance y definiciones de los casos
de uso.
CAL/Fundamentos 9

10. Productos Trabajo Del Diseño
 3. La especificación narrativa de CUS
representan la lógica para un caso de uso o
una operación individual.
 4. Siempre que una operación requiera lógica
significante,se puede emplear el diagrama de
actividad para ayudar en su diseño. Esto a su
vez puede resultar en el descubrimiento de
otras operaciones mas pequeñas y reusables
que puedan proporcionar soporte para las
mas grandes y complejas. (...)
CAL/Fundamentos 10

11. Productos Trabajo Del Diseño
 (...) Cada operación también revela los
atributos que los objetos necesitan para
invocar la operación. Estos atributos
son agregados a la definición de la
clase para los objetos cuyo propósito
se acerca mas a los propósitos del
atributo.
CAL/Fundamentos 11

12. Productos Trabajo Del Diseño
 5. Los diagramas de clase
proporcionan la definición de objetos.
Cada operación y cada atributo
descubierto por su uso en otros
diagramas son agregados al diagrama
de clase. El diagrama de clase es el
repositorio definitivo y la fuente de todo
para la generación de código.
CAL/Fundamentos 12

13. Productos Trabajo Del Diseño
 6. El diagrama de estados identifica acciones y
actividades que se traducen en operaciones y
lógica de operaciones. Cada operación nueva
se agrega a la clase que define el objeto.
 7. El diagrama de estados representa el ciclo de
vida de un objeto único. Cada evento que el
objeto puede responder es representado con un
cambio de estados y comportamientos. Los
comportamientos específicos de estado son
representados como acciones y actividades.
CAL/Fundamentos 13

14. Productos Trabajo Del Diseño
 8. Los diagramas de interacción modelan los
eventos entre objetos y al hacer así
identifican las interfaces que los objetos
necesitan para recibir los eventos.
 9. Los diagramas de interacción se pueden
usar para derivar los diagramas de estados al
identificar estados candidatos y los eventos
que causan las transiciones entre estados.
CAL/Fundamentos 14

15. Productos Trabajo Del Diseño
 10. Las definiciones de clase proporcionan
los objetos que participan en los diagramas
de interacción. Las interfaces, descubiertas
en los diagramas de interacción, se traducen
en operaciones para las clases que definen a
los objetos participantes. Cada operación a
su vez identifica los atributos de la clase en la
forma de parametros de entrada
(argumentos) y valores de retorno.
CAL/Fundamentos 15

16. Productos Trabajo Del Diseño
 11. Los escenarios individuales en una
especificación narrativa pueden formar
la base para la comunicación de
objetos en un diagrama de interacción.
Los diagramas de interacción
frecuentemente identifican intefaces
complejas que requieren mayor análisis
usando otros diagramas, entre ellos
diagramas de actividad.
CAL/Fundamentos 16

17. Diagramas de Interacción
 Para beneficiarse de los diagramas,
necesitamos comprender la relación
entre los diagramas.
 Los diagramas:
 Presentan una descripción consisa de lo
que ud. conoce y decide acerca del
sistema
 Representan diferentes vistas de sistema.
CAL/Fundamentos 17

18. Diagramas de Interacción
 Juntos, sin embargo, los diferentes
diagramas representan un cuadro
completo de cómo está estructurado
el sistema y como trabajan los
objetos. Al comparar las diferentes
vistas, se pueden identificar
inconsistencias y mejorar el modelo
general.
CAL/Fundamentos 18

19. Diagrama De Estados
 En muchos sistemas, existen al menos
unas pocas clases de objeto clave que
sufren cambios sustanciales durante su
tiempo de vida. Para estos objetos, un
único evento puede resultar en muchas
respuestas diferentes basadas en las
condiciones actuales del objeto. La
condición del objeto es referida como el
estado del objeto.
CAL/Fundamentos 19

20. Diagrama De Estados
 Estado del objeto: El estado se define
por los valores de los atributos y las
relaciones del objeto. Por ejemplo,
cuando se abre una cuenta de crédito,
un intento de comprar un artículo
resultaría en una comparación del monto
comprado y el crédito disponible. Cuando
la cuenta de crédito es cerrada, un
intento de comprar artículos resultaría en
un error.
CAL/Fundamentos 20

21. Diagrama De Estados
 Igualmente, una relación puede
provocar una respuesta diferente. Por
ejemplo, cuando en el sistema de
boletaje un AsientoPresentación no
está asociada con un NivelDePrecio, no
puede venderse. Una vez que se
establezca el enlace con el
NivelDePrecio, el AsientoPresentación
se puede vender.
CAL/Fundamentos 21

22. Diagrama De Estados
 El diagrama de estados no se usará
para todas las clases del modelo. El
diagrama de estados es una
herramienta de propósito especial que
se emplea solo para objetos que
poseen substancial comportamiento de
estados específico. ¿cómo reconocer
esos objetos? ...
CAL/Fundamentos 22

23. Diagrama De Estados
 Una técnica es revisar los diagramas
de interacción e identificar aquellos
objetos que participan en muchos, o
mas aún en todos, los escenarios.
Específicamente, busque aquellos
objetos que tengan mas flechas de
evento entrantes, pues cada evento
entrante tiene el potencial de cambiar el
estado actual del objeto.
CAL/Fundamentos 23

24. Diagrama De Estados
 El objeto permanece en una condición o estado hasta que algo
le ocurra al objeto que active un cambio en el estado llamado
“transición”.
A B C
CAL/Fundamentos 24

25. Revisión D. Estados Notación
 Revisar la notación del diagrama de estados en la
presentación:
 UML – Diagrama de Estados.
 En el siguiente ejemplo se ayuda a empezar la
construcción de un diagrama de estados usando
un diagrama de secuencia como fuente. Los
ejemplos son muy pequeños de modo que se
puede enfocar en los mecanismos mas que en la
complejidad del dominio del problema. Pero la
misma estrategia se puede emplear a medida que
la complejidad del dominio se incrementa.
CAL/Fundamentos 25

26. Revisión D. Estados Notación
 Identifique los estados.
aGestionFacilidad aPresentación aAsientoPresentación
CrearPresentación
CrearAsientoPresentación El objeto no existe hasta
que el el evento lo crea. El
Hecho
objeto comienza en un
Hecho estado inicial: “sin precio,
no seleccionado, y no
vendido”
Caso de Uso: Planear Presentación
Escenario: Programar Presentación con éxito
CAL/Fundamentos 26

27. Revisión D. Estados Notación
 Identifique los eventos que activan la
transición entre estados.
aGestionFacilidad aPresentación aAsientoPresentación
CrearPresentación
CrearAsientoPresentación
Transición eventos
Hecho
Hecho
Caso de Uso: Planear Presentación
Escenario: Programar Presentación con éxito
CAL/Fundamentos 27

28. Revisión D. Estados Notación
 Dibuje el diagrama de estados
aGestionFacilidad aPresentación aAsientoPresentación
CrearPresentación
CrearAsientoPresentación
Hecho
Hecho
Sin precio
No separado
No vendido
Caso de Uso: Planear Presentación
Escenario: Programar Presentación con éxito
CAL/Fundamentos 28

29. Revisión D. Estados Notación
 Mezcle el nuevo diagrama con el diagrama
previo para formar un único diagrama de
estados para el AsientoPresentación.
aGestionFacilidad aAsientoPresentación
Sin precio
Precio(NivelDePrecio) No separado
No vendido
Hecho
Precio(NivelDePrecio
Sin precio
No separado
Caso de Uso: Planear Presentación
No vendido
Escenario: Programar Presentación con éxito
CAL/Fundamentos 29

30. Construir Un D. De Estados
 Ejercicio:
 Ver documento Word.
 Diseño III – Construir Diagrama de Estados
CAL/Fundamentos 30

31. Patron Diseño de Estado
 Cuando un objeto exhibe un conjunto de
comportamientos específicos de estado, el
código puede ser muy grande, complejo y dificil
de seguir. Para cada comportamiento que el
objeto pueda manifestar, la implementación
puede ser diferente por cada estado del objeto.
Por ejemplo, un objeto relativamente simple con
seis estados y seis comportamientos podría
necesitar 36 bloques de código de
implementación – un bloque por cada
comportamiento para cada estado.
CAL/Fundamentos 31

32. Patron Diseño de Estado
CAL/Fundamentos 32

33. Patron Diseño de Estado
 Una técnica para para cubrir la
complejidad de comportamientos de
estados específico es el patrón diseño
de estados. Este patrón usa el
concepto de delegación para separar la
implementación de un comportamiento
del objeto que es responsable por el
comportamiento.
CAL/Fundamentos 33

34. Patron Diseño de Estado
 Por ejemplo, muchos de nosotros somos
responsables de declarar impuestos. Sin
embargo, para algunos de nosotros, el
proceso es extremadamente complejo y
requiere asistencia de un experto.
Retenemos la responsabilidad final de
declarar impuestos, pero delegamos el
proceso a un especialista que lo hace
por nosotros.
CAL/Fundamentos 34

35. Patron Diseño de Estado
 Cuando el especialista en impuestos termina
el nos entrega resultados. La delegación
también se puede aplicar a objetos, por
ejemplo, una póliza de seguros proporciona
interfaces para enviar reclamos y cancelar la
póliza. Pero la implementación de estas
interfaces depende del estado (condición) de
la póliza. En la siguiente imagen se muestran
los componentes del patrón diseño de
estados usado para delegar la
implementación de estas interfaces.
CAL/Fundamentos 35

36. Patron Diseño de Estado
CAL/Fundamentos 36

37. Patron Diseño de Estado
 Cuando los comportamientos de un objeto
difieren dependiendo de un estado de objeto,
ud. puede definir nuevos objetos que
represente el estado del objeto. Cada unico
tipo de estado de objeto tiene su propia
implementación para cada comportamiento.
Cuando el objeto necesita un comportamiento
este “delega” el comportamiento a un objeto
de estado apropiado. Una vez que el
comportamiento está completo, el objeto
estado regresa el control al objeto original.
CAL/Fundamentos 37

38. Patron Diseño de Estado
 Veamos el ejemplo Java:
 Void SubmitClaim(Claim)
{ state.SubmitClaim(Claim) }
 Note como la operación simplemente
invoca otra operación del mismo nombre
sobre el objeto referido por el atributo
estado. La interface no tiene realmente
una implementación de su propiedad.
CAL/Fundamentos 38

39. Patron Diseño de Estado
 Transformar el diagrama de estados en
el patron de estados: El diagrama de
estados proporciona una descripción
explícita de los estados de un objeto.
Para crear el patrón de estados en su
diagrama de clases vea los siguientes
cuadros y siga los pasos.
CAL/Fundamentos 39

40. Patron Diseño de Estado
 El patrón de estados no es adecuado
para todas las aplicaciones de
comportamiento específico de estado.
Sin embargo, cuando uno encara un
numero grande de estados y una
variedad de comportamientos, el patrón
puede pagar buenos dividendos en
facilidad de mantenimiento y
comprensión.
CAL/Fundamentos 40

41. Patron Diseño de Estado
Crear un atributo sobre la clase
Base llamado estado o estatus o AsientoPresentación
estado
algo similar que convenga al
propósito.
CAL/Fundamentos 41

42. Patron Diseño de Estado
Sin precio No Disponible
No separado
No vendido
Para cada estado en el diagrama Precio(NivelPrecio)
de estados, crear su RemoverPrecio()
Con precio
No separado
correspondiente definición de No vendido
Disponible
clase. Cancel() Select()
con precio Reembolsar()
separado
Separado No vendido
AsientoPresentación
Compra(TipoPrecio)
estado
con precio
Vendido No separado
vendido
NoDisponible Disponible Separado Vendido
CAL/Fundamentos 42

43. Patron Diseño de Estado
Dibuje una relacion de
generalización desde cada objeto
estado hacia la única superclase.
AsientoPresentación EstadoAsientoPresentación
estado
NoDisponible Disponible Separado Vendido
CAL/Fundamentos 43

44. Patron Diseño de Estado
AsientoPresentación
EstadoAsientoPresentación
estado : EstadoAsientoPresentacion
0..* 1
NoDisponible Disponible Separado Vendido
El tipo de dato del atributo de Estado/Estatus de la clase base debería
referirse a la nueva superclase (esto permitirá que la clase base se
refiera a cualquier subclase estado a través de este atributo). El
símbolo de agregación se usa comunmente para indicar que la
generalizacion de estado es “parte de” el maquillaje de la clase base.
CAL/Fundamentos 44

45. Patron Diseño de Estado
Para cada evento en el diagrama de transición de Sin precio
estados: a) agregue una interface correspondiente al No separado
objeto base. B) agregue una interface correspondiente No vendido
(identica) a la superclase estado (esto provocará que Precio(NivelPrecio)
RemoverPrecio()
cada subclase estado herede las interfaces). Con precio
No separado
No vendido
AsientoPresentación Cancel() Select()
EstadoAsientoPresentación
estado : EstadoAsientoPresentacion Reembolsar()
con precio
Select()
Select()
Cancel()
separado
Cancel()
0..* 1 Reembolsar() No vendido
Reembolsar()
Comprar() Compra(TipoPrecio)
Comprar(TipoPrecio)
Precio()
Precio(NivelPrecio)
RemoverPrecio()
RemoverPrecio() con precio
No separado
vendido
NoDisponible Disponible Separado Vendido
CAL/Fundamentos 45

46. Patron Diseño de Estado
Un ejemplo Java para delegar comportamiento:
Void Compra(TipoPrecio) {Estado.Compra(TipoPrecio)}
AsientoPresentación
EstadoAsientoPresentación
estado : EstadoAsientoPresentacion
Select()
Select()
Cancel()
Cancel()
0..* 1 Reembolsar()
Reembolsar()
Comprar()
Comprar(TipoPrecio)
Precio()
Precio(NivelPrecio)
RemoverPrecio()
RemoverPrecio()
Para implementar las interfaces del
objeto base, invoque la interface
correspondiente sobre el atributo que
NoDisponible Disponible Separado Vendido
retiene la referencia a la subclase
estado.
CAL/Fundamentos 46

47. Resúmen
 Los estados y los comportamientos
específicos de estado son elementos
importantes de cualquier diseño final de
aplicación. El diagrama de estados es
una herramienta especificamente
diseñada para representar el estado del
objeto, los eventos de transición de
estados y el comportamiento específico
de estado en la forma de acciones y
actividades.
CAL/Fundamentos 47

48. Resúmen
 Los estados son representados por los
valores de los atributos del objetos. Las
acciones activadas por eventos
representan la implementación de los
eventos que causan el cambio actual
en el estado. Las actividades
representan comportamientos internos
al estado del objeto.
CAL/Fundamentos 48

49. Resúmen
 Aplicando patrones para simplificar el modelo:
El patrón diseño de estados es una forma de
manejar la complejidad del comportamiento
específico de estado y evitar codificación
complicada. El patrón de diseño de estado está
diseñado específicamente para distribuir y
aislar el comportamiento específico de estado.
Este arreglo hace que la solución sea visible a
nivel de modelo.
CAL/Fundamentos 49

50. Resúmen
 (...) En cualquier momento un
problema puede resolverse a nivel de
modelo en vez de con el código, el
tiempo y costos de mantenimiento se
reducen considerablemente.
CAL/Fundamentos 50

51. Resúmen
 Actualizar los productos del trabajo. Cada
vez que se agrega una nueva clase al
modelo debe reconciliar el producto del
trabajo nuevamente. La comprensión de la
relación entre los productos del trabajo
proporciona un conjunto de herramientas
que le ayudan a entender completamente y
describir el rol de cada nuevo recurso y su
relación con los otros elementos del
modelo.
CAL/Fundamentos 51

52. Resúmen
 Una forma que ud. conozca si su modelo está
bien diseñado es si es capaz de añadir nuevas
características con poco o ningún cambio al
modelo. Los cambios debería ser aislados en
pequeños subconjuntos de componentes del
modelo. En contraste, un pobre diseño
rápidamente crecerá en tamaño y complejidad
con cada comportamiento adicional. Un simple
cambio puede resultar en múltiples y
frecuentemente cambios redundantes en
muchas partes del modelo.
CAL/Fundamentos 52